For the emonSD release emonSD-30Oct18 (based on Stretch) SSH will be disabled by default for increased security.
SSH can be enabled by either:
The standard Raspbian way: adding a txt file in /boot called ssh
I see this being the preferred method of emonBase users where the SD card is easily accessible. A USB keyboard and HDMI monitor can also be used to create the file if no SD card reader is available.
Press and hold the emonPi LCD button for 5s
This would be the preferred method for emonPi users, see video demo:
The update to emonPiLCD.py for this enable SSH feature is currently in the gpiozero-enable-ssh branch of the emonPi repo.
To handle both sort and long press of the push button Iāve moved to using gpio-zero python library this has a really nice class for handling button inputs. Gpiozero has also improved the response time of the push button as you can see in the video.
The gpiozero lib can be installed with:
$ sudo apt-get install python-gpiozero
This install will be handled automatically as part of the emonpiupdate process.
Have you given thought to other security improvement opportunities, such as avoiding repeated use of publically known username/passwordās for emoncms, node-RED, MQTT, MYSQL etc.
Iām not sure. Whatās the attack vector you are trying to protect against because, as Paul says above, there are lots of other ways to access the emonpi that need closing off first.
ssh is both useful, and when an account is correctly protected with a strong password or key pair is about as good as it gets, and also sometimes the only way in if the web interface breaks.
I would much rather default to on and make disabling access a web admin option. The long-hold LCD button could much better be used for shutdown or restart as the press button on the side is fiddly and difficult to access.
Yes, certainly we have thought about all these things.
NodeRED
We will not be including NodeRED pre-installed in the next emonSD card image release. The reason for this is that no we will not be using the read-only root partition itās very easy to install NodeRED if itās required. Same with OpenHAB. Obviously not having services installed if they are not required reduces potential attack vectors.
MQTT @TrystanLea has been working on mqttauth. It sets the mqtt username and password to the emoncms admin username and password. Itās currently in the mqttauth branch on the Emoncms core: it sets the mqtt username and password to the emoncms username and password
. It also supports multiple emoncms accounts.
MYSQL
The MYSQL port is closed and only accepts connections via localhost therefore I believe itās already pretty secure.
I believe all other attack vectors are much less siginificant than having SSH enabled with a default password. Disabling SSH by default and moving away from a known default password is a big step forward for security. Now SSH is disabled there are no other ways to easily gain access to the emonPi. Especially if NodeRED is not installed and all ports are closed.
Agree, SSH is very useful if a user gets locked out of the web interface. This is why Iāve developed this feature to be able to enable SSH via a physical long press on the emonPi push button or by adding a file onto the boot partition of the SD card.
If we left SSH on by default and left it to the users to disable it if not needed then we run the risk of most users leaving SSH turned on with the default password. Itās far better IMO for the system to be in the most secure state by default.
IMO a good decision. Provided curl is installed, the node-RED update script command should install nodejs & node-RED very easily,
Hmm, I havenāt looked yet at the underlying code, but I assume once pressed for 5 seconds, SSH will be permanently enabled. What if the button is held down accidently for example picking up the unit, or pressed by a user not knowing the consequencesā¦
Meanwhile SSH would be enabled, and the user may not even be aware.
I donāt have a emonpi, maybe itās not a likely scenario?
Couldnāt the ālong pressā only be active when a menu item āAllow SSHā was displayed on screen?
That would make it a 2 stage process, and accidental activation would be minimised.
Taking that a stage furtherā¦ could the long press above be a toggle? so a long press to enable, long press to disable. This would allow users to make changes to the system via SSH, and then easily re-secure it again.
This feature has now been merged into emonpi master. All emonPiās will benefit from improved lcd push button response time after running emonpi update.
If security, or rather remote access, is becoming such a concern can I also suggest that on first boot the emonpi generates a random password for web access and prints it on the LCD - a 6 digit or lowercase string is enough - to prevent scanning attacks?
If things like SSH are off then that is to prevent remote access from outside the typical home / small office LAN and if SSH is routed then web services will also be routed in from the outside.
I did consider this, however it would add an admin overhead and a requirement of the user to keep a hold of the random password. Also the emonSD gets used on self-build systems and emonBase units that donāt have a LCD. I think disabling SSH disabled by default and prompting the users to change the password if they enable SSH is a good compromise. Iām assuming that most users who choose to enable SSH will understand the significance of properly securing it.
Sorry, I wasnāt clear - I meant for initial set-up only. You would be forced to change the password on first successful web access.
Also, if you concede that some people will not have an LCD then how do they enable SSH with a non-existent button?
Your product, but I still think avoiding SSH access to a platform like this is not right. The web interface is far more prone to abuse - especially a non real-cert protected one, which is would be on first boot.
@Bill.Thomson Please STOP editing my posts. If I make a spelling or gramatical error itās ON ME - not you.
Edited to remove sarcastic comment, but I am not removing the note that my post(s) have been edited without explicit consent.
This is the standard way the Raspberry Pi foundation handle enabling SSH. If you download a stock Raspbian image from RaspberryPi it will have SSH disabled by default. The /boot partition is FAT so easy to edit to add a ssh file on any PC.
Iām not a fan of this approach and just because Rasbian has done it does not mean it is something to be adopted. Their use case of Raspbian is significantly different to the EmonPi.
Once enabled, SSH stays enabaled, right? So really how does it help? A setup that forces the changing of passwords would be much better IMHO or even simply setup UFW to only accept SSH connections from the local network and while you are at it, block everything but those ports required.
I also have my doubts that Rasbian is the best base image for the EmonPi. It has too much baggage. As most will know I am a fan of DietPi. I think there would be some significant benefit with collaborating with those guys to produce an install script (the current āemoncmsā install is just an emonhub setup to emoncms.org).
If you are really so concerned about the security of devices that are possibly being exposed to the internet, then introducing SSL by default would be a major step forward. With LetsEncrypt it is a no cost (to the user) option as well.
[edit] Thinking about it, DietPi offers the ability to use a txt file that does a load of setup & āpackageā installs at first boot, so if there is an emoncms install package on DietPi, it would simply run that the first time the image is run. The txt file could also allow the wifi setting etc. to be defined before first boot.
Correct, when SSH is enabled via a long press of the LCD push button the user is presented with the default password and prompted to change it. Itās presumed that since the user chose to enable SSH they would change the default password as prompted to their own secure password. If a user did wish to disable SSH itās just matter of running:
Leaving SSH enabled is not insecure as long as itās got a strong unique password. It would be possible to extend the functionality of my push-and-hold feature to toggle SSH on/off if there was demand for this.
The goal for this feature was to move away from having SSH enabled with a default password. Only a small % of emonPi users will ever use SSH, in fact, most donāt know what SSH is! Those who choose to enable it will understand the importance of security with a unique strong password.
This issue was only accepting local network connections is that the emonPi is often connected to large educational and business networks itās certainly a security risk for any local user on these networks to be able to connect into the emonPi then they would be able to connect to the rest of the network, this is obviously very insecure and not something most users would want. The default setting for all home routers is to have SSH port closed to the outside word.
Yes, enabling SSL for emonPiās exposed on the internet would be really good. The issue is that the majority of users donāt expose their emonPi to the web directly, only accessing over a local network. SSL will not work on local machines without self-signed certs which will cause browsers to display worrying error messages.
Enabling SSL for all users by default is tricky. It would be best I think to put together a guide + script to help a user enable SSL if they did wish to open up their emonPi to the web.
DietPi is really nice, their current implementation of Emonhub posting to a remote Emoncms.org server works well. I discussed this with although I think running a full version of Emoncms with local logging is not compatible with how DietPi works. I discussed this a while back with the creator of DietPi.
This issue is that SD card is not easily user accessible on the emonPi, for emonBase users itās possible to enable SSH by putting a file called āsshā in the ā/bootā partition. It would not be a bad idea to add a method for an emonBase user to configure wifi via a txt file although the current WiFi AP mode network setup wizard works well and is more convenient IMO.
Hi @Paul, you mentioned on the staff thread that I ignored your comments on this thread. Iām very sorry if you felt this. This was not the case, I just needed to move forward with a working 1st generation working solution. My solution of a 5s long press on the LCD button to enable SSH can easily be improved upon in the future.
Your suggestion of being able to disable SSH via the push button is not a bad one. I just presumed that if a user chose to enable SSH they would then change the default password as prompted and leave it enabled for future remote access.
I would be happy to merge a PR from yourself for re-enabling SSH, you mentioned you started work on a proof of concept? I would be interested to review and discuss. Apologises for seeming to ignore your comment, I very much appreciate your feedback and continued support.
Ah OK, so this is primarily a mechanism to ensure a unique password is set? Could that not be done on first connection to SSH anyway?
Well that is simply not true. I have 3 different instances of EmonCMS (2x VM and 1 x Pi with HDD) all on a DietPi base that work flawlessly. āNot Compatibleā would have been true in RO FS days but not now. A number of the dependencies I install using the DietPi Software install route, a couple by command line.
Still YMMV. As I donāt use the predefined SD card it is a moot point for me.
There is a significant security issue with setting the SSH password on fist connection, how do we know that the first connection is made the correct user and not a rouge actor?
As I mentioned earlier SSH is not the primary method that users use to access the emonPi, the majority of users will never use SSH. Therefore itās highly likely that the SSH will stay active with the default password set forever.
Obviously, one option would be to ship each emonPi with a unique SSH password printed on a sticker on the enclosure. However, this would require uniquely programming each unit which add manufacturing complexity and cost and if the sticker was lost there would be no way to gain entry.
IMO the push button to enable is a simple effective solution we can use for the next emonSD release which is now ready for release.
Ah ok, my limited experience with DietPi has been using their pre-built SD card image. This is a discussion for a different topic. Maybe this is something you could try and take up with the DietPi dev team? Iām not sure how DietPi would work with the emonPi hardware, LCD, push switch etc. But Iām sure something could be figured out.
You said EmonCMS not EmonPi. All their base images are just that so can be written to an SD card. If they managed to put up an install for the EmonHub, I cannot see the EmonPi being a particularly tricky beast.
But, I am only pointing out the art of the possible. As I do not have an EmonPi it is of no value to me.
I donāt understand what risk is being claimed here? A local user on the network can connect to an emonPi and then connect to the rest of the network? I donāt understand why a local user on the network needs to go anywhere near the emonPi to be able to connect to the rest of the network? Why not connect directly to the target?
Also I would expect a large network to have administrators, and for it not be possible to connect the emonPi without the assistance of those administrators to assign an address, so they could set up an ssh password at the same time. Iād also expect them to be running guard software on the net to discover any port scanners etc, so I wouldnāt expect there to be any such threat.
