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
sshd
-
- OMV 4.x
- ptruman
-
-
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?
-
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
Codecp /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.
-
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
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-customBash
Alles anzeigen#!/bin/bash OMV_SSHD_CONFIG="/etc/ssh/sshd_config" sed -i "/HostKey \/etc\/ssh\/ssh_host_rsa_key/d" ${OMV_SSH D_CONFIG} sed -i "/HostKey \/etc\/ssh\/ssh_host_dsa_key/d" ${OMV_SSHD_CONFIG} sed -i "/HostKey \/etc\/ssh\/ssh_host_ecdsa_key/d" ${OMV_SSHD_CONFIG} sed -i "s/LoginGraceTimer 120/LoginGraceTimer 60/" ${OMV_SSHD_CONFIG} echo "Banner /etc/issue.net" >> ${OMV_SSHD_CONFIG} exit 0
omv-mkconf ssh
This will survive upgrades but won't work on OMV 5.x. -
As you can see in https://github.com/openmediava…kconf/ssh.d/10sshd_config you can customize many options via environment variables. Everything else you can do in a customer script as @ryecoaaron mentioned above.
-
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.
-
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.
-
And after 20 years not a single one was found that really broke ssh.
-
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.
I meant a broad security context. Not necessarily OMV. For 0day on IOS, apparently they pay up to 2 million.
-
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.
-
Resurrecting zombie-thread
I was starting to look into Salt - but can't easily see how to set up new states, as (to me?) omv-salt isn't 'salt'?
I've got around this for now by updating /etc/default/openmediavault and adding
OMV_SSHD_CHALLENGERESPONSEAUTHENTICATION="yes"
and then
omv-salt stage run prepare
It would be good to have the SSH Challenge option in the GUI
-
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.
This was a good hint that helped me achive the same banner goal, yet it feels more of a hack. I think it would be a good idea to include the SSH banner setting in the GUI aka Workbench, at least for the upcoming 7.x.
pi@omvhost:~ $ cat /srv/salt/omv/deploy/ssh/30sshd_banner.sls
/etc/ssh/sshd_config:
file.append:
- text:
- Banner /etc/issue.net
pi@omvhost:~ $
I ran omv-salt deploy run ssh && systemctl reload sshd and I was done with it.
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!