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.)
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:
SSH disabled - physical access to the SD card or the machine running on it is required to enable it.
SSH enabled with no/default password - essentially free access to everything by anybody from anywhere.
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.
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.