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.
As I mentioned in in first post
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:
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.
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.
Hate to break up the party, but… Off Topic guys!
This thread is about disabling SSH.
Paul
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.
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
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.
As the rationale for disabling SSH by default was to mitigate the risk of users port forwarding at the router and exposing a default password, might there be a different approach.
Firstly, this could be maintained for EmonPis shipped from the factory.
For the downloadable image, why not restrict SSH logins to be from localhost by default? It seems restricting SSH login to 192.168 range of IPs is reasonably simple either by UFW configuration or by SSHD config.
That’s an interesting idea. However, I still think for highest security it’s best to have SSH disabled for all IP’s by default. The effort required to enable is minimal and especially since SSH access is not required for normal usage.
Security by default should be a priority rather than expect users to secure their own systems. I would be horrified if I bought a new laptop which came shipped with SSH enabled by default with a published default password, IMO an emonPi is just the same. A RaspberryPi 3 is a powerful computer which could be used to do a lot of harm on a network if compromised.
A possible solution could be to have a product option for the emonBase/emonPi in our webstore where customers could check a box if the want SSH enabled on their unit. Although I do think this is overkill considering that the methods we have for enabling SSH are not difficult. Especially if we include a micro SD card adaptor with all emonBase’s which we are now doing as standard.
We could also have a version of the emonSD available for download with SSH enabled. However, if someone is able to flash their own SD card then they must have an SD card reader, creating a /boot/ssh file would then be trivial.
Could I suggest that the physical button be developed to allow it to both enable AND disable SSH. It could act like a toggle, and the LCD display could display its current state, so holding down the button for 5 seconds, the LCD displays “Press again to enable SSH” and is either user confirmed or times out after 5 seconds. Similarly, the LCD displays “Press again to disable SSH” and again is either user confirmed or times out after 5 seconds.
If the emonSD image was then supplied with SSH enabled by default, this would allow users the chance to setup their installation without further problems, before locking it down.
The emonpi setup guide could make it quite clear that after installation, that SSH should be disabled, and if it’s just pressing a physical button I don’t think that’s too much to ask!
You could even put a paper sticker on the emonpi to reinforce.
You may recall that I made this suggestion a month ago, before the new image was finalised -
In fact, @glyn.hudson later did say he would be prepared to look at this option -
For emonHub users, it would be trivial to add a soft-button - ‘disable SSH’ in the ‘Administration’ page, so users could again setup their system and then as a final step, disable ssh, IF THEY WISH TO.
I think it’s important for users to have options - one size doesn’t fit all!
IMO, it also makes much more sense than providing different versions of the emonSD image, one enabled, one disabled, etc.
Paul
A toggle is a good idea. That way SSH can easily be disabled once the user has finished. There is already a script to disable SSH in place:
I’m very keen to have security enabled by default. Rather than making security an extra step the user has to do, which most users might not do. I guess we could make two versions of the emonSD image available to download. However, if a user has the capability of downloading and flashing an emonSD image then creating a /boot/ssh if SSH is required should not be a problem.
SSH access is not essential for standard emonSD operation.
Sure, I would also be happy with a software button to disable SSH. But not to enable SSH. However, I guess you may not want to Emoncms user to be able to disable SSH. Personally, I think if a user does want to disable SSH then toggling the LCD button or running ~/emonpi/lcd/disablessh.sh sufficient. I’m not sure we need a button in Emoncms, but I don’t really mind either way.
It should be noted that even though there has been a couple of posts on the form regarding users asking how to enable SSH, I don’t think it’s as big of an issue as it may seem. We have shipped 96 emonPi units with the new image and only 2 users have reported issues enabling SSH.
I think overall the inconvenience of having the push and hold the LCD button for 5s or drop a file on the SD card to enable SSH is worthwhile for the greater good of a more secure system.
A seriously compromised emonPi could potentially cause a lot of damage to a network, the Pi3 is a powerful computer with a high bandwidth internet connection. It would be irresponsible for us to ship units with SSH enabled. My only regret is that we did not implement this sooner, relying on users to change their own SSH password was a mistake.
What do you think of adding an alert to emonPi-update to alert users if they have SSH enabled with the default password unchanged?
I don’t see a 5 second push of a button unreasonable, compared to emonhub users having the inconvenience of pulling the SDcard and modifying the OS.
You are acting responsibly by providing a easy way for emonpi users to disable SSH, and advising them to do so. If they ignore that advice, then it’s the user acting irresponsibly!
I’m not making light of security, but to keep this in perspective…
In the total history of supplying emonpi’s, how many emonpi’s have been compromised or subjected to a SSH attack? Have any been reported in the forum?
Yes, good idea. If this was introduced, it would be another reason favouring a standard image with SSH enabled, because the alert should… well…alert the user.
Just to be clear, are you talking about the emonbase which does not currently have a push button? Adding a push button in future is an option, perhaps the easiest would be an SMT push button on the RFM69Pi, but it would add cost, retooling etc and take time to implement. Perhaps that’s a good long term solution?
I personally feel the same way as Glyn that adding the ssh file to enable ssh is a minor inconvenience for the additional security benefit. I’m also in favour of the default secure approach. Although I can see the emoncms disable SSH software button and an alert working I would prefer it to be disabled to start with.
Perhaps we need a poll? And time to assess how often this issue crops up?