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.
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.
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?
No, the emonpi push button which Glyn refers to above. It’s surely no hardship for users to disable SSH by using the button (if the emonSD came SSH enabled).
It’s much more of an effort by emonhub users having to pull the SD card etc, just to get it working.
TBH if that was true, then you would have HTTPS and UFW installed and configured. Possibly also something like PiVPN. What about the default MQTT and database passwords held in clear in the settings.php? You have picked up on one specific security aspect. A Pi exposed by ports being opened is still going to run as HTTP, have an MQTT server with a default password etc etc. Don’t kid yourself that not enabling SSH by default makes it ‘safe’ to expose the Pi to the big bad world - you might not have said that, but it is the implication is there for anyone who might think SSH being disabled makes things safe.
The advice should be DON’T unless you fully appreciate the risks.
That was a good idea by @borpin earlier about using UFW to only allow localhost access. I use the same myself, and it’s as easy as blocking all access, then adding an ‘allow’ rule; sudo ufw allow from 192.168.1.0/24 to any port 22
This would mean that SSH port 22 would only be accessible from within the private network, and we could then forget about disabling SSH altogether, usb card readers, hdmi cables etc. and find another use for ‘The Button’
As far as I’m concerned having SSH disabled by default is non-negotiable. It’s totally ridiculous to suggest we put all emonPi’s at risk of being compromised for the sake of a few moments to push the button or create a file. Taking the SD card out of the emonBase is very easy and does not require a screwdriver. The vast majority of users will never need SSH, it’s crazy to have it enabled. The Raspberry Pi foundation thinks the same, here is a blog post discussing why they felt the need to disable SSH by default.
SSH has the highest attack vector and the worst consequences if compromised. It’s the logical first thing to secure. I’m well aware of the other attack vectors, but none are as easy to exploit as an unsecured SSH. We’re working hard to increase security in all areas:
We do not recommend users open up their emonPi to the world.
The MariaDB database on the new image is configured to only allow connections from the localhost.
It’s true that the MQTT ports is currently open with a default password. This is required for communication with smart plug and openevse units. However, MQTT is read-only and it’s it’s not possible to compromise the whole system via MQTT. We plan to close this MQTT port closed by default then users can choose to open it if required. Security is always a compromise between ease of use vs security.
The issue is that your private network may be someone else’s corporate or university network, we don’t want the emonPi being the soft target to anyone on these networks looking for devices to compromise.
I don’t have a emonpi, but I do have a SD card reader, HDMI cable, screwdriver and a big hammer - which I sometimes use as a screwdriver, so this doesn’t really affect me in any way.
I’ve posted here to present a user & logical perspective, and thereby support & help openengymonitor develop & flourish, but if you are drawing ‘red lines’ and ignoring what your customers, users & forum members are requesting then surely that’s not in the ethos of opensource software development.
I’m not seeing any posts supporting your view, but for me, I’m bowing out of this discussion and won’t be posting further.
I’ve been watching this discussion.
My view is it’s fundamentally wrong to lock the user out of their own system. There should be a mechanism for them to obtain access. It seems to me that the original problem was a user thought they could access the emonBase via SSH, but they couldn’t and initially didn’t know why. The discussion should be about the feasibility and the merits of the best way to allow the user in.
It seems that your (@glyn.hudson) assumption that a card reader would always be available was wrong, in this particular case at least. So while it’s accurate to say that accessing the card is easy, the next step failed because no card reader of the right size, nor adapter (which the OP didn’t know about) was available. The gripe here is, in this particular set of circumstances, it was not possible to modify the SD card. And at present, there is no alternative mechanism.
One other aspect to consider: while it’s laudable to try our best to look after our users’ security, and there’s a degree of obligation to do so as we’re “experts” (at least in the eyes of some users), at the end of the day, the users have to look after themselves, because we cannot cater for every possible scenario.
If I recall correctly, I might have made a suggestion that a random (or pseudo-random) password should be used. Obviously that could be written to the SD card and printed on the label, but it would be costly in operator’s time. Or it could be generated at first start-up, but then it is inevitable that sooner rather than later, it wouldn’t get written down, or it would be written down and then lost.
Concentrating on shutting off SSH as the most likely vector probably increases the chances of defeating a penetration of the network, but there’s an absolute certainty that any possible way in will be exploited sooner or later.
We will be including a micro SD card adaptor with every emonBase. A USB keyboard and hdmi monitor could also be used to login and create a /boot/ssh file if needed. These are basic peripherals that most users should be able to get hold of if needed.
However as we know ssh access is not required to use any regular feature of emonpi/emonbase/emoncms. The primary interface is via a web browser therefore I do not consider disabling ssh by default as locking a user out of their system.
As an “EmonBase” user, the first thing I did after changing the password was enabling ssh. I can see both sides of this argument and the number of posts in this forum where the troubleshooting and subsequent remediation involve sshing into the Pi and running some shell commands seems to indicate its a frequently required thing.
Is it frequently required for EmonPis where the user is expecting a plug and play solution? Probably not.
Is it frequently required for EmonBases where people tend more to be tinkerers? I would think so.
I think this is the crux of it.
As I see it there’s three main groups of consumers here:
EmonBase users with a shop bought micro SD card pre-loaded with EmonSD
EmonBase users with a downloaded EmonSD image subsequently written to a micro SD card
The following “easiest” solutions exist for these groups:
Press and hold the button on the EmonPi.
Find a micro SD card reader, or a keyboard, monitor/tv and HDMI cable and make the appropriate changes
Create the /boot/ssh file - they’ve already got the card loaded into a reader.
IMHO, this assumption was the key error in making this decision.
If we break the problem down, it is that the people in category 2. must rely on external things they may not have access to. Pragmatically, the answer seems to be to fix that, which makes ssh being enabled or disabled by default largely irrelevant (regardless of any personal preferences).
I’ve not really got any great ideas on how to solve this… The simplest seems to be making the button functionality available on the EmonBase, but that requires the user to short two pins using something they had to hand and hope they didn’t jumper 3.3V or 5V to ground! Thinking out loud, how much overhead would there be to supply a “jumper plug” with EmonBases to do this safely? Have I just suggested creating more plastic waste?