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!

    • change permissions for root directory : chmod 755 /root

    chmod 755 /root isn't the same thing as chmod 755 /

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 5.x on ASRock Rack C2550D4I C0 Stepping - 16GB ECC - Silverstone DS380 + Silverstone DS380 DAS Box.

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

  • I had the exact same issue on a fresh setup and chmod 755 / did the trick.
    Is there possibly an issue with the base install of OMV5?

  • 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.6.6 usul | 64 bit | 5.11 proxmox kernel | omvextrasorg 5.6.1
    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

  • Wow, thank you for this info! I was really concerned about running chmod 755 / however I did. I can now ssh into my omv 5 installation with PKA. I had spent too much time troubleshooting that.

  • The fix is only applied when you install the package the first time. You can manually run omv-salt stage run setup.

    Can someone explain what this does? I ran it, but aborted it. There was no output. It was a dumb to run it when I didn't know what it did.

  • Can someone explain what this does?

    It sets up OMV saltstack.


    I ran it, but aborted it. There was no output.

    Why? No output on Linux usually means nothing is going wrong.


    It was a dumb to run it when I didn't know what it did.

    No offense but OMV probably does lots of things that you don't know what they do. When the OMV dev suggest something, you can assume it is the right thing to do.

    omv 5.6.6 usul | 64 bit | 5.11 proxmox kernel | omvextrasorg 5.6.1
    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!

  • No offense but OMV probably does lots of things that you don't know what they do. When the OMV dev suggest something, you can assume it is the right thing to do.

    No offense taken on my part at all. You are right, OMV does a lot of things I don't understand. :D 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.

Participate now!

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