Simply making the task of this action:
sudo touch /boot/ssh
That should be the only necessary command to execute
I really think asking them about this saves a lot of trouble when they cant access keyboard via ctrl+alt+f1 in experimental version, etc… so basically letting them know that enabling this will allow remote access for much better management and that they must change the default raspberry pi password (or it is really recommended since we cant really force it)…
What do you think? @vpetersson
@ealmonte32 - While that may seem like an obvious and great thing to do at first glance, the problem is that unless you also combine that with the mandatory password change of the user account, you open up the device to a big security risk. This is essentially why the default behavior changed a few years ago in Raspbian from having SSH enabled by default to having it being disabled by default.
Hence, if we were to implement something like that, it would almost require a mandatory password change as you correctly point out. It’s not rocket-surgery, but there are a few moving parts.
I’ve spent a fair bit of cycles in the last few months thinking about what the best user experience is for Screenly OSE without compromising too much on the security part. I’ve looked closer at solutions like Proxmox, pfSense and FreeNAS. All of these products offer the ability to pop open a shell (or VNC session) that gives your root access directly from the management interface. If we were to hypothentically add such functionality in Screenly OSE, we obviously would need to start by adding proper permission structures to lock down the access.
Historically, I’ve been against using just regular SSL/TLS (with self-signed certificates), as it doesn’t really protect against MiTM, but perhaps I need to give in on this and accept this constraint (much like Proxmox/pfSense/FreeNAS are doing).
Hence, to answer your question, perhaps a better solution is to:
- Create proper access controls
- Allow some kind of Shell/VNC within the web interface
(To make matters more complicated, this becomes somewhat challenging given that we are in the process of migrating the services to run inside Docker for better security, which obviously impacts the above.)
I understand the security concerns, but there should be a balance between security and usability from the remote management side, think about all the users that once the screenly device is behind a TV or monitor somewhere, they can’t easily go and plug a keyboard and run commands, etc, thus having at least the option (and explaining all the security risks and the suggestions), I think it will be appreciated by those who understand the need for it.
Perhaps during screenly install, after asking question about SSH, if user says “Yes”, cant we execute:
chage -d 0 pi
which will force password change on default account…
I am just throwing it out there, we can think about how to best go about it, but I like your ideas on proper access controls and allowing for shell access from web interface… which reminds me, VNC installation question can also be asked for those users who would need to enter credentials on websites like that user on github recently asked, again, I am just thinking of making screenly have all available options laid out for the user to choose and decide… what do you think?
Regarding the docker migration: yup, if you want to implement some shell from web interface then this wont be easy but it is possible, but SSH and VNC setup and configuration during install-ose script should definitely be an option, just my very strong suggestion.
Let me think a bit more about this one. In a perfect world, Web Interface+VNC, combined with self-updating should be sufficient.