Fixing Public Key Authentication

  • 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!

  • Well what I did was a really simple workaround, and I don't know why permissions on the rootdir were wider in the first place - maybe there was a specific reason and maybe restricting permissions broke something else - I didn't investigate further than what I explained so I wouldn't know.

    For what it's worth, I think that restricting rootdir permissions should be done regardless of SSH, and so far I have had no adverse effects on OMV 5.

  • This problem was fixed here - https://github.com/openmediava…8f16244e87e18d0a7180e2cc8 and here - https://github.com/OpenMediaVa…ba1199b79c0b1c416200fa7a1



    Is there possibly an issue with the base install of OMV5?

    It was an issue with some Debian installs (nothing OMV can fix) and some Armbian installs

    omv 5.5.2 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.3
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • Hello :)

    I've just spun up a new HP Microserver with OMV 5 Usul, and hit this exact problem.

    I am using 5.5.2-1 from the website ISO, and SSH was broken nicely for me until I ran the chmod, so the fix may not be applying?


    Jun 11 11:47:37 openmediavault sshd[13466]: Authentication refused: bad ownership or modes for directory /


    uname -a reports


    Linux openmediavault.citadel 5.5.0-0.bpo.2-amd64 #1 SMP Debian 5.5.17-1~bpo10+1 (2020-04-23) x86_64 GNU/Linux

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!