sshd

  • Where does OMV hide it's default sshd_config, or what script does it run on save config?
    I'm hardening my config manually, but if I touch any thing in OMV, it resets it - and re-includes lines I've removed.
    Adding NEW lines via OMV is fine, but I can't "occlude" stuff from there. Ideally I'd like to use the GUI but so far have to avoid it - unless I can fudge it's defaults :)

  • Where does OMV hide it's default sshd_config, or what script does it run on save config?

    /usr/share/openmediavault/mkconf/ssh.d/10sshd_config but if you change that file, it will be reverted when you install OMV updates. What hardening are you doing?

    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!

  • Basically this


    From the GUI - denying root login, enabling compression and enabling PubKeyAuthentication (which are all retained)


    Then:

    • Installing Google Authenticator (for OpenVPN AS also)
    • Generating an appropriate account Google Auth file
    • Removing/commenting out

      • HostKey /etc/ssh/ssh_host_rsa_key
      • HostKey /etc/ssh/ssh_host_dsa_key
      • HostKey /etc/ssh/ssh_host_ecdsa_key
    • Adding the lines:

      • HostKey /etc/ssh/ssh_host_ed25519_key
      • ChallengeResponseAuthentication yes
      • Banner /etc/issue.net
    • Amending the line:

      • LoginGraceTimer (change from 120 to 60)
    • Editing issue.net appropriately with message of choice
    • Then running
    Code
    cp /etc/ssh/moduli /etc/ssh/moduli.orig
    ssh-keygen -t ed25519 -f ssh_host_ed25519_key -N "" < /dev/null
    ssh-keygen -G /etc/ssh/moduli.all -b 4096
    ssh-keygen -T /etc/ssh/moduli.safe -f /etc/ssh/moduli.all
    awk '$5 >= 3071' /etc/ssh/moduli.all > /etc/ssh/moduli.tmp && mv /etc/ssh/moduli.tmp /etc/ssh/moduli
    rm /etc/ssh/moduli.all
    systemctl restart sshd


    I've generated (and been using) an ed25519 key with PuttyGen.


    That basically gives me the best possible cypherset (removing legacy ones) 3 factor auth (public/private key with appropriate username in cert, Google Auth code, plus account password matching the underlying Debian account) and regenerates custom moduli files (removing unsafe/lower value ones) and regens the system keys.

  • I think this is unnecessary. My OMV4 configs already have the ed25519 line and you could just symlink the newly generated key to the other filenames.


    ChallengeResponseAuthentication yes

    I think this is a bit much. I would just run sshd on a different port and use the fail2ban plugin if you have people trying to hack you that much.


    Banner /etc/issue.net

    If you really want to change these, you could make a file to change/add the values:
    echo 'OMV_SSHD_CHALLENGERESPONSEAUTHENTICATION="yes"' >> /etc/default/openmediavault
    nano /usr/share/openmediavault/mkconf/ssh.d/30-custom

    omv-mkconf ssh
    This will survive upgrades but won't work on OMV 5.x.

    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!

    Edited 2 times, last by ryecoaaron ().

  • Those are the pointers I was after, ta.


    Re: changing port, I have - but if you check out shodan.io - you will find that your machine (if exposed) has probably been fingerprinted, so all a port change does is stop drive-by scripted attacks. Anyone running nmap/fingerprinting will find the ssh service and what protocols it's willing to deal with. Fail2ban does help but as it's not saving to a DB it resets on any reboot and some clustered hacks just rotate to another IP


    Also, having had two passwords lost (and confirmed on haveibeenpwned.com) I don't want to leave any exposed service down to just user/pass - so Google/OTP helps there.


    I've got another layer on top of that which arguably makes it more secure, but that's away from the OMV box :)

  • Re: changing port, I have - but if you check out shodan.io - you will find that your machine (if exposed) has probably been fingerprinted, so all a port change does is stop drive-by scripted attacks. Anyone running nmap/fingerprinting will find the ssh service and what protocols it's willing to deal with.

    I've had ssh ports open on the internet for almost 20 years and unless you are running some super important server (I wouldn't use OMV for that), changing the port to something non-standard has dropped attacks from thousands to almost none in all cases in my experience. I know nmap can find it but no one is scanning all 64k ports on every IP address on a regular basis.

    Fail2ban does help but as it's not saving to a DB it resets on any reboot and some clustered hacks just rotate to another IP

    Just a suggestion.

    Also, having had two passwords lost (and confirmed on haveibeenpwned.com) I don't want to leave any exposed service down to just user/pass

    I don't. I use keys only with root disabled. I would never leave an ssh port open to the internet with password auth.

    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!

  • There is a place for everything, but in combination with restricted tries per minute even a strong password can be fine.
    If you want to harden your server like that I would seriously consider to build the stuff myself from a hardened image rather than using omv per default.

  • Perhaps it is best not to expose sshd to the world? Unless it is absolutely necessary .... Or hide them behind something else that will stick out.
    Once, for over a decade, I had a dedicated server in a large company. SSH was exposed to an unusual port on typical settings and f2b. We did not have the keys, there were only 64 characters long randomly generated passwords and no access to the root remotely. No penetration has ever been observed using sshd. If something was already generating problems, it was Apache and I was worried about him always and not about sshd ....

  • Brute forcing user name and 64 char pws does take a hell lot of time. And there were not a lot of bugs in ssh until now, I remwmber the one where you could bf the username without pw as the most severe right now. If its only about scripted attacks, port knocking will remove pretty much all of them.

  • Brute forcing user name and 64 char pws does take a hell lot of time. And there were not a lot of bugs in ssh until now, I remwmber the one where you could bf the username without pw as the most severe right now. If its only about scripted attacks, port knocking will remove pretty much all of them.

    I try to follow the philosophy that if something is exposed to the world, there is always 0day risk. If someone wants to use the tin foil hat concept, maybe he should think about not making the sshd available to the world. Perhaps an IP access restriction. Hide sshd so that it is only reachable locally. Knock the server by vpn, zerotier or something else and then sshd. Can also think about an appropriate access policy using fw + ids.
    Anyway, whether ssh or web or mail is always a 0day risk.

  • Anyway, whether ssh or web or mail is always a 0day risk.

    0days especially ssh 0day are worth a lot of money. People who have these 0days are not going to bother with someone's OMV box.

    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!

  • Where have these configs moved to in OMV5? :)

    IRN : I'm moving to guacamole, behind traefik with oauth, but I still like ed25519, which (as yet) is only in libssh2, which needs 1.9, which isn't in debian buster by default (yet).

  • The files are located at /srv/salt/omv/deploy/ssh/, but you should not touch that files, otherwise you work against the package management and how OMV works. Simply add another Salt state which includes the changes you want to apply to be on the safe side.

Participate now!

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