emonPi SSH disabled by default

peter · 2018-10-16T12:17:33.394Z

“Hmm.”

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.

glyn.hudson · 2018-10-16T16:25:28.531Z

Paul:

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.

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.

peter:

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.

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.

peter:

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.

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.

peter:

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.

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.

Paul · 2018-10-16T19:41:32.827Z

glyn.hudson:

We will not be including NodeRED pre-installed in the next emonSD card image release.

IMO a good decision. Provided curl is installed, the node-RED update script command should install nodejs & node-RED very easily,

glyn.hudson:

Press and hold the emonPi LCD button for 5s (to allow SSH access)

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?

TrystanLea · 2018-10-16T20:17:17.355Z

Paul:

What if the button is held down accidently for example picking up the unit, or pressed by a user not knowing the consequences…

The LCD prints “SSH enabled” after 5 seconds, so as long as the user is looking at the screen, the message is quite clear?

Line 226 here shows the event detection for the button press Gpiozero enable ssh by glynhudson · Pull Request #68 · openenergymonitor/emonpi · GitHub which ultimately calls the subprocess to enable ssh here: Gpiozero enable ssh by glynhudson · Pull Request #68 · openenergymonitor/emonpi · GitHub

Paul · 2018-10-16T20:25:47.359Z

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.

…just ideas to consider…

Paul

glyn.hudson · 2018-10-17T17:02:24.226Z

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.

github.com/openenergymonitor/emonpi

Gpiozero enable ssh

openenergymonitor:master ← openenergymonitor:gpiozero-enable-ssh

opened 07:01PM - 15 Oct 18 UTC

glynhudson

+111 -58

- move to gpiozero library to handle button presses `sudo apt-get install python…-gpiozero' - Enable ssh by holding push button for 5s - Push button response improvements

Please feedback any issues here.

peter · 2018-10-18T09:25:37.852Z

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.

glyn.hudson · 2018-10-18T13:47:58.667Z

peter:

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?

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.

peter · 2018-10-19T07:15:41.516Z

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.

glyn.hudson · 2018-10-19T16:01:16.427Z

peter:

Also, if you concede that some people will not have an LCD then how do they enable SSH with a non-existent button?

As I mentioned in in first post

glyn.hudson:

SSH can be enabled by either:

The standard Raspbian way: adding a txt file in /boot called ssh

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.

borpin · 2018-10-21T10:20:08.705Z

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.

glyn.hudson · 2018-10-21T15:52:52.643Z

borpin:

Once enabled, SSH stays enabled, right? So really how does it help?

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:

sudo update-rc.d ssh disable
sudo invoke-rc.d ssh stop

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.

borpin:

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.

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.

borpin:

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.

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.

borpin:

[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.

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.

glyn.hudson · 2018-10-21T15:59:51.424Z

Paul:

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.

…just ideas to consider…

Paul

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.

borpin · 2018-10-21T20:07:45.515Z

glyn.hudson:

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.

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?

glyn.hudson:

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.

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.

glyn.hudson · 2018-10-22T17:15:56.340Z

borpin:

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?

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.

borpin:

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.

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.

borpin · 2018-10-22T21:21:11.517Z

glyn.hudson:

I’m not sure how DietPi would work with the emonPi hardware

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.

Paul · 2018-10-22T21:38:45.214Z

Hate to break up the party, but… Off Topic guys!
This thread is about disabling SSH.

Paul

djh · 2018-11-25T12:47:20.939Z

glyn.hudson:

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.

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.

TrystanLea · 2018-11-25T16:27:51.225Z

Hello @djh, thanks for asking.

The risk we were trying to mitigate against was one where the home user enables port forwarding on their router to provide remote access to their emonpi/base, but leaves the default emonpi SSH password in place. An attacker could search for web accessible devices and try their luck.

Alternatively if an attacker has access to the local network (less likely), SSH disabled is better than SSH enabled with the default password.

This practice of disabling SSH with the option to enable by placing a file called ‘ssh’ in the boot partition is applied by raspberrypi themselves Raspberry Pi Documentation - Remote Access

Hope that’s helpful

djh · 2018-11-25T20:57:17.986Z

Hi Trystan, thanks for the explanation.

Yes, I can understand the home user risk, albeit one could argue that anybody opening ports ought to check the implications first. My question was about the large, professional network risk.

I think it’s all probably moot though given the current pressure not to ship IOT devices with shared default passwords. Politics probably trumps any risk assessment.