@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.)