Harden SSH

Hello everyone,

I'm trying to harden SSH on OMV but I'm hitting a roadblock.

I've disable root login and forced key authentication only, anyway I'm struggling in hardening the ciphers, the key exchange algorithm and the message auth codes.

My ideal configuration would be something close to:

KexAlgorithms curve25519-sha256@libssh.org
Ciphers chacha20-poly1305@openssh.com
MACs hmac-sha2-512-etm@openssh.com

But with this configuration, when connecting (I only used Putty and the built-in SSH client on the Mac) I get a connection error.

The most secure configuration I managed to get is instead:

KexAlgorithms diffie-hellman-group-exchange-sha256
Ciphers aes256-ctr
MACs hmac-sha2-256

Even simply adding the MAC hmac-sha2-512 prevent Putty from conencting.
Adding any other Cyphers but aes256-ctr or any other Kex but diffie-hellman-group-exchange-sha256 prevent Putty from connecting as well.

Do you have any suggestion on how to achieve the desired encryption level (which would get rid of all the less secure ciphers)?

Thank you.
Tommy

Hi @WastlJ,

Thanks for your input.

I do have Key auth working, and to be fair with common ciphers that is working very good.
I have got a 4096 bit key and I successfully connect when using:

• KexAlgorithms diffie-hellman-group-exchange-sha256
• Ciphers aes256-ctr
• MACs hmac-sha2-256

My question is actually, how do you get stronger ciphers working on OMV?
The ciphers I want to use are stronger and more robust and they guarantee a higher level of encryption/security.

The one I want to use (and that seems not to work with OMV at this very moment) are:

• KexAlgorithms curve25519-sha256@libssh.org
• Ciphers chacha20-poly1305@openssh.com
• MACs hmac-sha2-512-etm@openssh.com

Hope that clarifies my question.

Thanks,
Tommy

LOL

Yeah, I'd quite like to keep SSH as secure as possible given I get few thousands of random connection attempts from random IP's throughout the day.
I'm aware this would be superfluous as nobody broke in yet but, given I do not rely on iptables (and therefore I cannot user fail2ban) I think this is the only option left.

ideally I would also like to reduce the timeout to 5 seconds (from the default 30 seconds) and increase the server key size to 4096 bit but I know the sshd_config file gets re-written at every reboot.

Tommy

@WastlJ, no, no public IP even though it never changes.
I'm suing a CNAME (for a friendly URL) that via DynDNS points to my OMV as I need to access it from internet from time to time.

@ryecoaaron, as a workaround I've been turning off SSH and only enable it via the WebUI when I actually need to use it.
As a workaround it does work as good as changing port I reckon. The only thing is that I was looking to secure the shell as a "best practice".

Regards,
Tommy

Hey @subzero79,

That is an excellent suggestion

I was not aware of these env variables which actually control the server key size and the grace timeout (2 things I was looking to change):

ssh: OMV_SSHD_X11FORWARDING=yes
ssh: OMV_SSHD_KEYREGENERATIONINTERVAL=3600
ssh: OMV_SSHD_SERVERKEYBITS=768
ssh: OMV_SSHD_LOGINGRACETIME=120
ssh: OMV_SSHD_PUBKEYAUTHENTICATION=yes
ssh: OMV_SSHD_HOSTBASEDAUTHENTICATION=no

Nothing wrong with iptables, never thought they're inadequate or bad.
I found sometimes difficult to work with iptables as given 2 of my OMV are running on Azure I may lock myself out.
This happened when I tried once to DROP by default and allow 80,443 and 22 but I reckon I had set an incorrect order and that prevented me from using both SSH and the WebUI.
This why I avoid using them if I can - just to avoid doing something stupid again

Of course this does not apply to OMV running on the HP Micrsoserver as I can always use ILO to connect via shell.

Regards,
Tommy

Yeah, I have been using knockd when on a CentOS VM on DigitalOcean.
That was quite good and I was using a sequence to open the port and another to close the port (when a short open-time was not an option).

On Azure is quite different as even if you get a public IP you have n/w ACL's that controls the endpoints (for a max of 255 ports open per IP) which implies the used ports are quite easily guessable.
This means, I would only have ~ 245 ports available for the knocking with which a 5 port sequence would imply 5^245 combinations; still a lot (5.5*10^174) but far more guessable than 5^65000.

I will be looking to change the following env variables as a starting point:
OMV_SSHD_SERVERKEYBITS=768 to 4096
OMV_SSHD_LOGINGRACETIME=120 to 5

I will also check if I can find any way to get a more recent version of OpenSSH (like the Wheezy back-port one you suggested).

Good calla bout the OSX Yosemite limitation due to OpenSSH 6.2.
Will try to find out if El Capitan has got any update, SSH wise.

Thanks,
Tommy