emonPi SSH disabled by default

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?

We don’t know of any. But the issue is highlighted by the recent nodered issue caused by default passwords. That you highlighted :slight_smile:

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.

Yes, good idea.

Not really, it will just get forgotten about.

Thanks for the clarification.

emonhub is already running and can be configured via the emoncms web interface. No SSH required.

@djh needed it

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 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’ :sunglasses:

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.

Oh dear!
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.


Could I get some other opinions from other users?

I can’t believe that in late 2018 I’m having to defend a decision not to ship a device with open access enabled with a default password! This is basic security.

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:

  1. EmonPi users.
  2. EmonBase users with a shop bought micro SD card pre-loaded with EmonSD
  3. EmonBase users with a downloaded EmonSD image subsequently written to a micro SD card

The following “easiest” solutions exist for these groups:

  1. Press and hold the button on the EmonPi.
  2. Find a micro SD card reader, or a keyboard, monitor/tv and HDMI cable and make the appropriate changes
  3. 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?

1 Like

I am very pleased to see security being taken this seriously.
This is a good solution to a serious potential flaw.
Given the fact that the password is known password and you can get a javascript ssh client and mDNS works having the ssh daemon on by default will enable drive by attacks where a user visits a page located on the web in that then causes their web browser to connect to the local emonpi via its .local domain name. The web browser has kindly removed any protection that was provided by a firewall. These kind of attacks have been seen in the wild on routers already.
By forcing a user to turn on the ssh daemon they are much more likely to also change the password.

Other possibilities would be to only enable ssh if there was a private key and the password was not set but those would still all need added.

My two cents, since I inadvertently stirred this hornet’s nest. I was trying to start an emonBase; I don’t NEED ssh access but I feel a lot more comfortable when I do have it, so I tried it, when I got to the point on 1. Connect - Guide | OpenEnergyMonitor where it is mentioned. (i.e. the Assign static IP section) It failed, and there’s nothing on that page that tells me why (for that matter, I see there’s a typo - shh for ssh - so even the cut-and-paste commands aren’t :frowning: ) So the first thing I would suggest is updating that page to match current reality.

Then I searched for the symptoms, both here and on google, and didn’t find anything about the emonBase in particular but did about the pi in general, so I started a thread to check the facts.

It turns out there are two possible ways to enable ssh and it so happens that I can’t do either simply. I believe an adapter will be shipped in future, so in my particular circumstances I would have been able to enable ssh fairly easily, if I had been told I needed to.

I also intend to buy a spare HDMI lead, since I think its a sensible thing to have (I used my last spare in the hi-fi rats nest). So I would be able to use either method to enable ssh. It just happens to be an irritation this time because of the particular hardware I happen not to have.

Incidentally, shorting two pins together is not an approach I like. Firstly I would have to dismantle the device to access the pins, and secondly it’s quite error-prone.

I do appreciate the attempts to make the system more secure, and as has been pointed out, there are several other weaknesses that should be addressed. I’m no expert but is it worth doing an analysis of security specifically - maybe the likes of OWASP could help?

It’s true, assigning a static IP is one of the few actions that SSH is currently required for. This could in the future be included as part of the WiFi GUI setup.

Thanks for reporting, this has now been fixed:

Did you manage to get static IP to work? Think that section may need to be updated for Raspbien Strech. What worked for you in the end? I’ve not tried setting up static IP on Stretch yet. Best discuss this on a new topic

That’s good to hear.

I agree.

We’re reviewing all aspects of security following the UK Gov publication on “Secure by design IoT code of Practice”: Secure by Design - GOV.UK

Unsurprisingly it states that default passwords should not be used and all unnecessary ports and access services should be disabled (points 1 and 6)

We have a legal responsibility under GDPR to enable security by default for our users. This is why I consider this decision to disable SSH by default non-negotiable. We are reviewing the security of all aspects of the system.

Sorry, no idea. I had set up a static IP on my router (mentioned in my thread) so that wasn’t what I was trying to do; it was just the point that testing ssh access occurred to me.

Is that review process open? Are conclusions and rationale published somewhere, for example, and open to discussion?

Certainly, we will be posting on the forum any changes we make. Happy to discuss any aspect of security openly.

@TrystanLea is currently working on a more advanced authentication for Mosquitto MQTT server using your Emoncms admin login to authenticate with MQTT.

@emrys is also working on an Emoncms remote access feature via MQTT over TLS without opening any ports.

Given that the emoncms login and password are sent in the clear, that doesn’t seem very secure.

edit: Oh I just got ssh working. I’ll post details on my thread, as it wasn’t straightforward.