Hi everyone,
I hope I'm posting the right thing in the right section - please tell me if otherwise.
I have been trying to make public key authentication work for a long time on OMV, and after a few hours of troubleshooting I think I understand the problem better.
What I'm trying to achieve
Allow a user created via OMV web GUI to open an SSH session with Public Key Authentication
My configuration
- Fresh install of OMV 5.4.3-1
- No plugins
- Installed on a dedicated physical host
Issue & steps to reproduce
- Create a new user (hereafter referred to as "bob") in OMV web GUI
- Assign bob to ssh group
- Generate a keypair with PuTTYgen
- Add the public key (in RFC4716 format) to the user in OMV web GUI
- Restart SSHD service
- Connect to OMV via PuTTY with private key configured
- Get "Server refused our key" error message and prompt for password
My findings
- I understand that OMV creates users without homedirs, and cannot use /home/bob/.ssh/authorized_keys to store the public key
- Therefore, the config file (/etc/ssh/sshd_config) is modified to add AuthorizedKeysFile with 3 entries, which SSHD will scan in order until it finds a relevant key :
- .ssh/authorized_keys (standard directory)
- .ssh/authorized_keys2 (also standard for ssh2 with legacy clients)
- /var/lib/openmediavault/ssh/authorized_keys/%u (where %u is replaced by the user trying to connect) --> this is where OMV stores keys added via GUI
- Scanning auth logs (/var/log/auth.log) reveals an important error :
Authentication refused: bad ownership or modes for directory /
This means that the root directory's permissions are unsatisfactory for sshd to trust the authorized_keys file stored in /var/lib/...
Indeed, permissions for "/" are set to root:root 775, which means group-writeable - whereas SSHD needs every directory in the path to authorized_keys to be only owner-writeable.
Proposed resolution
IMO there are two ways to deal with this :
- change permissions for root directory : chmod 755 /
--> This solution is confirmed working, but even though it's standard best practice, I cannot confirm that it doesn't cause any side effects. - Disable SSHD StrictMode, which runs multiple checks to validate SSH auth : in /etc/ssh/sshd_config, change StrictModes to no
--> This solution works but is not desirable as sshd puts these control for good reasons, mainly to prevent exposing sensitive files.
Does this sound like the right way to handle this ? Maybe there was a simpler way ?
Cheers!
I know enough to get myself in trouble. I'm generally careful about just running commands from the web on my computers. I like to understand what is going on. So, the command wasn't dumb, my action in running a command without knowing what it does was what was foolish. Just glad it didn't 'break' anything. I finally got it all setup, as an active backup environment. That is why I'm cautious. Thanks for the input.