Enabling SSH by default

I am updating from the 2017 version to the latest 2021 version. The shell script enablessh.sh does not seem to exist.

creating /boot/ssh using
sudo touch /boot/ssh
does seem to work. I now have ssh access to the emonpi. I can control it remotely rather than having to connect it to a keyboard and monitor.

In my opinion ssh should be enabled out of the box.

1 Like

Hello Nigel, I’ve moved this to a new thread as the original was quite old. The reason for disabling SSH access by default is that we ship the SD card with a default SSH password, it has been ‘emonpi2016’ for years. Disabling access reduces the chance that this would be used maliciously.

The emonPi has had the ability to enable SSH via the push button but it’s always been more of a hassle with the emonBase, do you have the emonBase? or did the push button not work?

We have been discussing however having a mechanism of enabling SSH from the emoncms user interface as it is a real hassle having to put the SD card in an SD card reader to add that /boot/ssh file for emonBase users (I forget to do it myself almost every time). For those who remember, we did argue quite strongly against this a few years ago but I think we’ve come round to the view that it would be good to have a solution for this. If enabling and disabling SSH is accompanied with password protection and the mechanism requires changing the default SSH password it might not pose too much of a security risk.

But then, if you’ve just written the SD card with dd, balenaEtcher or whatever, it’s very easy.

I think the only solution is to request the user to set and write down the new SSH password on first boot - and there’s still got to be a recovery mechanism somewhere, because some/many new users will inevitably be confused and unsure of what they’re doing and why, and will forget/lose their new password.

(I don’t use the password - I have a pair of key files set.)

1 Like

Thanks Robert, your right that requiring the password to be set at first boot is probably the best option, would that then leave SSH enabled or would you still have the option to turn SSH on/off via the interface?

I’m not entirely sure what you’re getting at. Once you’ve got a good password or better, a pair of key files, SSH can be left enabled. Disabling SSH physically adds some security - depending on how good the password is. But you must not enable SSH without.

This is essentially a 3-state setup:

  1. SSH disabled - physical access to the SD card or the machine running on it is required to enable it.
  2. SSH enabled with no/default password - essentially free access to everything by anybody from anywhere.
  3. SSH enabled with a ‘good’ password or key file pair - access to holder(s) of the password/key file.

Once set, the password is as secure as a password is, anyone will expect that having set the password, SSH will be enabled, with a reminder that the password just set will be required to allow access by SSH (or indeed to install the key file pair!).

My key file pair doesn’t have a password set - this machine is authorised for SSH access, not me. (And this is OK, the machine is password protected and the SSD encrypted.) I was wondering whether a key file pair like that could be generated on first boot, the private file copied to the user’s machine and then erased from the SD card.

Once the key file pair is installed, /boot/ssh disappears. The escape route is to put the SD card back in the user’s machine and generate a new key pair; or (presumably, I haven’t tried it) put /boot/ssh back.

I am trying to find the apache (and other) access log files to see if there are any hackers trying to infiltrate my system. The logs are not in /var/log/apache2. In the absence of hacking evidence I would prefer a simpler approach leaving things open and minimising the requirement for different login ids and passwords. The emonpi 2021 os is running on a pi 3 on the local network with no ports open. It needs to run headless in a cupboard and SSH or some form of rlogin is essential. There is no “push button” on my Pi 3. Why would someone want to mess with my energy monitoring system? I am reluctantly upgrading from the 2017 version that was working (nearly) fine. I find the terminology emonpi, emonhub, emonbase, emoncms and emoncms.org totally confusing. I hope I can get back to a robust working system.

I appreciate and am grateful for the work that has gone into the emon system which allows me to monitor the energy, charge the car and heat the water from the energy of the sun. I am inspired by the simplicity of updating Chromebooks and Teslas and which have a simple, single login.

emonpi - a raspberry Pi, with an add-on board that accepts two CT inputs and is housed in an aluminium case with an LCD screen and a pushbutton. emonPi Energy Monitor - Shop | OpenEnergyMonitor

emonbase - a raspberry Pi with an add-on radio module that cannot do Power measurements. emonBase - web-connected base-station - Shop | OpenEnergyMonitor

emonhub - a component of the EmonCMS Energy monitoring software that accepts various data sources and turns those sources into “Inputs” within the EmonCMS software.

emonCMS - the energy monitoring software that runs on an EmonBase or EmonPi. It can also be self installed onto other operating systems.

emoncms.org - a version of emoncms hosted “in the cloud”, managed and maintained by the creators of OpenEnergyMonitor - Emoncms.org Credit - Shop | OpenEnergyMonitor

All described reasonably well here: System Overview - Guide | OpenEnergyMonitor

1 Like

I’d agree with that.

Take card out of PC, put card back in (to remount boot), create blank file.

I think this should not be enabled by default. RPi OS even forces a user and password of first boot now.

@TrystanLea, could this be enabled from EmonCMS interface?

How about a second password entry option at the point that you register the admin emoncms user? With a note about what an SSH password is?

1 Like

That’s the upside. The downside is you’re totally dependent on that ecosystem that’s there primarily to make money for its provider. As we’ve see a few times, when that provider pulls the plug, you have a system that can’t be supported by anybody else.

As with all things, you pay your money and you make your choice.


A commercial system will endeavour to do that. Include Apple in the list of easy to use technology. I’m not sure “simplicity of use” and “commercial systems” (with the danger of plug pulling) are inextricably linked though.

I realise there is a lot under the hood of an emon system with the hardware, message passing, node-red routing, graphics and posting online all working harmoniously. But then a Tesla is like that. It is simple to use and very few are stolen.

High chance of it being forgotten.

IIRC there was something somewhere that forced password change on first SSH login. If the SSH could be enabled from the interface, when logging in, the password would then be forced to be set.

Alternatively, enable it for a fixed period (more complicated I’d suggest).

Or create a Pi User based on the emoncms user and SSH using that username/password?

A post was split to a new topic: Using a DS18B20 with an emonPi