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!

    Einmal editiert, zuletzt von th3m1773n () aus folgendem Grund: Formatting, and typo in root

    • 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 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

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

    • Offizieller Beitrag

    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 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    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

    • Offizieller Beitrag

    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 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    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.

  • Can someone help me to get my ownership corrected for my user to be able to ssh into my omv5 box with ssh keys?

    i've got the public key added for this user in the web ui.

    What command do I need to run to change the ownership and keep the "Server refused our key" from happening via Putty log in.

    Thanks!

  • I looked in /var/lib/openmediavault/ssh/authorized_keys/%u <-- replacing my %u with my user's name.

    I also chmod'd this directory to be 755.

    When I log in via putty, it's still refusing my key.

    Not sure what else to do. It appears that everything is configured correctly.

    I'd like to turn off my password authentication for this user when connecting to my OMV box.

    Any help would be greatly appreciated.

  • Have you enabled public key authentication in OMV | Services | SSH?


    What does the public key look like in an editor - all on one line or multiple lines?


    Where did you generate the key?


    When you copied the key to OMV exactly how did you do it?

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


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

  • The issue I think is that I thought this was the only area that needed keys. I deleted these entries out of the /root/.ssh directory.

    authorized_keys

    id_rsa

    id_rsa.pub


    Do the files in the /root/.ssh directory need to have these entries, or since I'm logging in with a non-root user do they even apply?



  • The id_* entries in the /root/.ssh directory belong to the root user. If it turns out you need them in the future they will have to be regenerated.


    You haven't answered my other questions.

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


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

  • The id_* entries in the /root/.ssh directory belong to the root user. If it turns out you need them in the future they will have to be regenerated.


    You haven't answered my other questions.

    Expand the comments section above, I answered them in bold.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!