Volumio is a great player and I applaud the hard work building the system. But Volumio’s own internals (SSH, Samba, plugins, updates) depend on a hardcoded username and password (volumio/volumio) which is somewhat awkward to say the least.
I appreciate most users want a simple system but I suspect they also expect good practice basic security. SSH with a known password is particularly risky. SSH gives shell access to the underlying Linux system, so an attacker could modify the OS, install malware, pivot to other devices, or use it in a botnet.
More or less everyone on the planet is familiar with setting login credentials and the Raspberry Pi Imager helps automate this. So there are no barriers there and suggesting using a VLAN is not a solution as most user never login to their router and have no idea how it works.
The security concern is well documented and in 2017 a SSH plan was mentioned but with v4 we still have a hardcoded password?
Can the community treat this as a priority and help Volumio move this forward with a solid plan.
Volumio, despite being based on Linux, is not a generic Linux distro. Comparing it to one is apples and pears, and that comparison is not going to help anyone reach a useful conclusion.
It is a purpose-built music player, no different in intent from any other appliance firmware in the world. Appliance firmware ships with known service credentials because the device is designed to be operated as an appliance, not administered as a server.
For exactly the security reason you raise, SSH is disabled by default. It has to be explicitly enabled by the owner via the dev page. The repeatable mantra here is simple: keep it disabled unless required, and disable it again when you are done.
No, it is not. Neither is the main web UI. The trust boundary on an appliance like this is the network it sits on, not the application served from it. Anything on the LAN that can reach the player is treated as trusted, by design.
That is the same model used by virtually every consumer audio appliance. If that trust boundary is not acceptable for a given deployment, the correct place to address it is the network, not the firmware.
You can keep repeating the same statement if you like, but let’s recap reality once more:
– Volumio is a music player.
– It announces itself on your network, just like literally every other music device.
– If you enable SSH for no reason, leave it wide open, and expose the device to the WAN… then yes, congratulations, you’ve built your own security problem.
Think of it like a house:
– Volumio is the stereo inside your house.
– It’s visible on your local network, just like your front door is visible from the street.
– That’s perfectly normal.
Problems only start if you unlock the front door (enable SSH), leave it wide open, and then build a highway straight to it from the internet (expose it to WAN).
At that point, it’s not the house that’s unsafe — it’s how it’s being used.
“Zero security” is your phrasing, not mine. What was actually said is that the /dev page is not behind a separate password. That is not the same statement.
The actual posture of a stock Volumio install on a normal LAN:
SSH is off by default. No shell exposure exists until the owner deliberately enables it.
There is no WAN exposure. The device does not punch holes in your router, does not phone home for remote admin, and is not reachable from the internet unless you yourself put it there.
The exposed services on the LAN are the ones a music player needs to do its job: the web UI, MPD, UPnP, AirPlay, and the Samba share for Internal Storage. That is the appliance surface, and it is a defined surface, not an oversight.
The trust boundary is the LAN. That is the same model your router admin page, your printer, your NAS out of the box, your smart TV, and effectively every other consumer appliance on that same network uses.
That is a security model. You may prefer a different one, and that is a legitimate preference to hold. It is not the same as the device having none.
If your specific deployment mixes trusted and untrusted clients on one flat network, the correct layer to address that at is the network, because that is the layer where the trust boundary actually lives. Moving the boundary into the firmware does not fix a flat network. It just adds a password prompt in front of an otherwise flat network.
Something that has been discussed, however it raises problems with plugins. Plugins need admin credentials to install packages, there is not an easy way to get this implemented.
This would be awkward for a media player. Can’t recall any that has this implemented, do you?
To solve my network share security concerns I’ve added a new user without a home directory or password and added the user to Samba. I then changed the Samba conf to require a username and password to mount the Internal and USB shares. I disabled the NAS share as this was not required for my set up.
Volumio is not listed as a Samba user and SSH is disabled on v4.119 so there’s no need to change anything on the default account.
I’m happy to manage Samba accounts and shares for my devices but ideally this would be part of the configuration and password protected.
A short factual note on moOde, since this is a Volumio forum and not the place to catalogue another project - moOde’s config WebUI is not password-protected either. What it requires is a login userid and password set via Raspberry Pi Imager’s OS Customisation before first boot, used for SSH and system login. That is not the same thing as a WebUI auth gate.
On @Wheaten’s plugin point, the blocker is not hand-waved. Plugin installs invoke sudo and touch system paths, so the install pipeline currently depends on the volumio account being a known identity on the local system. Decoupling per-install user credentials from the plugin installer’s privilege path is the actual piece of work, and it is not small.
Your own Samba approach - new user, smbpasswd, valid users, restart - is the correct shape of the fix at the smb.conf layer, and the fact that it leaves the stock account untouched is the right instinct. I do not dare think how this impacts OTA, mind. Whether that pattern ends up as a supported configuration option is a product-level call, not a technical one.
Even so this is not user friendly, but to reduce the risks related with ssh you can create a ssh-key by entering
ssh-keygen -t ed25519
in the PowerShell, then enter a passphrase (optional) or just press enter, then copy the created key file id_ed25519.pub from C:\Users\YourName.ssh\ to Volumio (again in PowerShell)
After this you can loggin from the device where you have stored the ssh-key simply by entering
ssh volumio@IP-ADRESS
After you have verified that you can connect like this you can completely disable password login (for ssh):
Open the configuration file on your Volumio device via SSH:
sudo nano /etc/ssh/sshd_config
Search for the line PasswordAuthentication yes and change it to PasswordAuthentication no. Save the changes with Ctrl+O, then exit with Ctrl+X.
sudo systemctl restart ssh
I’m not sure if this causes conflicts with OTA updates, but I believe the /home directory (where the SSH key is stored) remains untouched during an update.
For the installation of plugins I do not know, but however, if it does not work you can change in /etc/ssh/sshd_config from PasswordAuthentication no to PasswordAuthentication yes