emonPi SSH disabled by default

We did consider this but I think shorting pins jumper is more risky and has the potentially to go very badly wrong if a user accidentally shots the wrong pins. Also accessing the GPIO pins can require fully disassembling the unit. Removing the SD card to creating a /boot/ssh file is easier and much safer IMO.

I was keen to avoid the increased attack vector of allowing SSH to be enabled via the web. This is not to say that it’s not impossible to implement in a secure method.

Interesting idea, however it’s well publicised that within seconds of being connected to a network with an open port onto the web a machine receives botnet attempted logins. For the sake of the minimal effort required to push the button for 5s or create a file on the SD card I think it’s worthwhile for the added security of having SSH disabled right from the beginning. Especially since I already mentioned the vast majority of users will never need or want to use SSH.

This is a good idea.

Just to clarify, emonSD / emonBase does not require SSH access to use Emoncms. Even on first boot the user can log in directly to Emoncms via web browser and create a user account. All configuration of emonhub, WiFi etc can be done via a web browser. If no Ethernet connection is available the unit will start a Wifi AP to allow the WiFi to be configured, see the user setup guide:

https://guide.openenergymonitor.org/setup/connect/

BUT there is no processing of that data being carried out by a data controller so I’ll say it again - no data controller - no GDPR implications.

An EmonPi connected to emoncms.org where OEM will be deemed to be processing that data and is therefore a Data Contoller is different but only wrt the data on their system that they are processing. How it got there is neither here nor there [edit] well not quite as black and white but in this context correct.

I will note that neither ‘open energy monitor’ nor Megni are registered with the ICO. Data protection fee | ICO

BUT there is no processing of that data being carried out by a data controller so I’ll say it again - no data controller - no GDPR implications.

Storing personal data is processing. Even if there is no personal data on emoncms.org, Megni definitely processes personal data for the purpose of selling stuff from their own website so they will be a data controller for this reason at least.

I will note that neither ‘open energy monitor’ nor Megni are registered with the ICO. https://ico.org.uk/for-organisations/data-protection-fee/

Not all organisations have to register, it depends on what they are doing, but all organisations must comply with the DPR. Small businesses are treated slightly differently but the provisions are broadly the same.

Of course it is, but an EmonPi in my house connected to nothing (even if it was I’d argue it, itself, is not subject to GDPR), is not subject to GDPR so the argument that SSH must be disabled because of GDPR is a fallacious argument. If that was true, then any system connecting to emoncms.org would need to have the same levels of security!

Agreed, but I’d like to see what exemption you’d offer to OEM. Pretty sure they need to register and pay a fee (if you process orders you need to cough up).

As this was my suggestion as well, I’d just like to say in context that it was specifically applicable to the EmonBase, which unless I’m mistaken isn’t actually “an assembled unit”. You can also manufacture a “jumper block” that would make it almost foolproof to jumper the correct two pins together.

I’m seeing the same behavior I called out before - people seem to forget there is more than one category of end user and they didn’t all buy an EmonPi.

Just sayin’

1 Like

Thank you @borpin for the heads up on that, looks like we missed that step, we have now registered and should be listed once the application has been processed.

2 Likes

FWIW, my emonBase certainly is a fully-assembled unit.

Most users choose the enclosure option for the emonBase, almost every emonBase we ship is an assembled unit.

While technically possible for us to design manufacture a custom jumper block I do think this is slightly overkill just for enabling ssh! It would add cost, complexity and would easily get lost and wasted by most users since the majority will never need to use SSH. I still think the default method chosen by the RaspberryPi foundation of creating a ssh file in the boot partition is not too difficult. The microSD is easy to remove from the emonBase and the boot partition is FAT so automatically mounts on any Mac or PC.

I don’t believe this is true, we our down our best to support the emonBase. It’s just convenient that the emonPi has a handy physical push button we can utilize. In the saw way the emonBase cannot display the IP address or power value since it does not have an LCD screen. It’s just a difference in hardware. We will always continue to support the emonBase.

Ok, I’d not been able to find the pictures in the Shop of what the enclosure looks like, so I assumed it was like every other Pi case out there - two pieces of plastic that clip together. Hardly what I’d call “assembled” in the same manner that the EmonPi is with a daughter board and a screwed together case.
Yes, I know the emonBase has a daughter board, but it only covers half of the pins in the expansion connector, nothing actually needs to be “disassembled” to get to the other half of the free pins.

Exactly why comments about “displaying the random password on the LCD screen” are only catering to a portion of the user base. My comment was unfairly directed at the OEM/shop folks, it was actually intended for the wider group of people responding in this thread. I’ll edit my post to make that clearer.

I’ve avoided wading in on the SSH enabled/disabled debate because its not what I believe is what requires discussion. The Raspberry Pi foundation have it disabled by default, OEM have chosen to disable it by default, so it doesn’t seem unreasonable to me.

However, if you sell something to people who need specific items in order to enable what could arguably be a required feature for troubleshooting, and those items do not come with the product, you really need to either supply those items or call it out to the consumer that they will need them to perform that troubleshooting.

Sure, it’s not a big task to disassemble. But still more involved than removing the SD card which is easily accessible.

Thank you.

Exactly, I think this is the main issue here. We should continue to work hard to ensure SSH is never required. I feel like we have made good progress on over the last few years. All configurations and setup can be done via the web interface. Log files can also be accessed, backups created and restored and software package versions checked all via the web interface.

One of the few tasks that still require SSH access is setting up a static IP network. This is something which could be added to the emoncms WiFi module.

I feel that instead of focusing on the requirement for SSH we should instead focus on how we can not require SSH.

Sure, most users here on the forum will use SSH, that’s fine, I obviously use it a lot myself. However, we need to recognize that we are technically savy power users. Many users will not even know what ssh is. It’s unfair to expect non technical users to secure their systems. This is why I’m so keen on ensuring the system is security by default.

And yet, probably less involved than extracting an already in-use HDMI cable out of your entertainment unit, finding a USB keyboard and then finding somewhere to plug them all in after you realise you don’t have an appropriate card reader. :stuck_out_tongue:
FWIW, I agree that supplying an “ssh enabling jumper” with every emonBase is probably overkill. It was just a thought.

In general, I think this is the right approach, but there’s clearly still a way to go on this. Until we get there, we need to make sure that everyone that purchases an emonSD image on a card has a guaranteed way to get SSH enabled so they can get into the operating system they’ve just bought.

There are really three options already available, so pragmatically, we need to work out how we make sure everyone knows what they are and can easily find the details.

  1. Keyboard and monitor (HDMI) connected to the Pi: login to the console and enable it (either creating /boot/ssh, running the emonPi enabling script or doing it yourself manually)
  2. Card Reader that can read/write to a micro SD card (or a standard SD card for anyone that gets an adapter with the store order now): create an empty /boot/ssh file on the boot partition which is readable from Windows/Mac
  3. If you have an EmonPi: press and hold the button for 5 seconds.

How do we best make sure that information is available when needed, without requiring people to search the Internet?
Is it worth putting those instructions behind a Troubleshooting section in the Web Administration console?
A printed flyer in the package with the pre-loaded SD card?
Are the various posts available on the forum already sufficient? (it would seem not, as this hornets nest was kicked again by someone not finding them and asking the question)

2 Likes

Good points @Greebo lets do that. I will have a look at it today.

Just to clarify, emonSD / emonBase does not require SSH access to use Emoncms. Even on first boot the user can log in directly to Emoncms via web browser and create a user account. All configuration of emonhub, WiFi etc can be done via a web browser. If no Ethernet connection is available the unit will start a Wifi AP to allow the WiFi to be configured, see the user setup guide:

Sorry, but am I the only one to see the irony here? To be clear for those who don’t: The system is open and listening for admin access on an even easier to access protocol than SSH. How is this secure?

1 Like

Hello @peter, are you referring to emoncms user account creation or the Wifi AP here?

I’ve added the following note to the emonbase and emonSD shop items:


Advanced Users: SSH is disabled by default on the latest emonSD image.
SSH can be enabled by adding a file called ‘ssh’ to the /boot partition.
See: Service Credentials - Guide | OpenEnergyMonitor


emonSD:
https://openenergymonitor.com/emonsd-pre-loaded-raspberry-pi-sd-card/

emonBase:
https://openenergymonitor.com/emonbase-web-connected-base-station/

Edit: added line “Or on the emonPi, pressing the emonPi LCD push-button for 5 seconds.” to the emonSD product page as it may be used in both.

2 Likes

Just because a web interface uses http instead of https doesn’t mean it is inherently insecure. That is a common misconception. It is less secure in particular circumstances, certainly, but how many of those apply to an EmonCMS interface on a home network?

When you first plug it in at home, unless your local network is completely open to incoming connections from the Internet, you can only access that web interface from your local network. Once you have accessed it and configured an admin username and password of your own choice, I don’t understand the specific risk you’re calling out.

The real risk I can see is if there is an inherent security flaw in the EmonCMS web interface pages, and that would apply regardless of whether it was http or https. Have you found one? If so, I’m certain Trystan and Glyn would be very interested to hear about it so they can fix it.

Apologies but this has gone way off the topic of ssh, perhaps it should be in a different thread titled “http vs https: security by default” or something?

Just to be clear, I’m not advocating against a move to https. I’m just trying to temper the opinions being expressed around security of EmonCMS.

With Lets Encrypt certificates available for free with automatic renewal, its now easier then ever to use https, and it certainly should be looked at, but it isn’t the dire security emergency people are making out - at least regarding EmonCMS.

Nothing in my reply mentioned http. The same “hole” exists in a default set-up page using https. If you believe that an SSH service is insecure from first boot then an https one is too.

You’ll need to clarify what you’re talking about then. Unless everyone else knows and I’m the only one in the dark.

http vs https has been raised numerous times in the discussion about “secure by default” so if you were concerned about something besides ssh, that was the most obvious choice, especially since you didn’t actually explain what you meant.

I’m still in the dark about what you’re actually talking about…

If you start up a freshly built emonsd then there is an open web service that lets you create a user account and off you go. It doesn’t have a default password, it has no password at all. This is no better than having SSH access with a non-root account that prompts you to change the password on first login.

And I covered that in my post - I still fail to see what the issue is?