4 ms·

Following the Hardening Guide link [1] I see that most server configs consist of the same 3 steps: * Re-generate (and enable) the RSA and ED25519 keys * Remov

by j1elo 3y ago

Following the Hardening Guide link [1] I see that most server configs consist of the same 3 steps: * Re-generate (and enable) the RSA and ED25519 keys * Remove small Diffie-Hellman moduli * Restrict supported key exchange, cipher, and MAC algorithms As an ignorant of security matters, my obvious question is: if these are such an important thing to configure, why servers don't come with them done by default? There must be thousands of people who don't know about this guide, don't necessarily know a lot about security hardening, and would benefit from more secure defaults. I get "because compatibility" might be a reason, but that would only maybe apply to the last point, wouldn't it? [1]: https://www.ssh-audit.com/hardening_guides.html https://www.ssh-audit.com/hardening_guides.html

efitz 3y ago
Many (most?) releases auto generate the SSH server keys and set default configuration during OS or during SSH server enablement. Changing the server key protects you against the case that whoever made the distribution did it wrong - either used duplicate keys to other hosts, or intentionally compromised the key, or used a poor PRNG, or used a less desirable algorithm, perhaps for compatibility purposes. That is not to say that any of those things actually happened; it’s just that the most paranoid/defense-oriented view is not to trust what the OS did for you, but to do it yourself. A distro provider is incentivized to find a local optimum between security and compatibility and has no idea about your environment. You have much more context about your environment- you know what you need to connect to, what needs to connect to you, and what ciphers, key length, and other configuration that you must support. Therefore if you take all that into account you might be able to optimize for security by disabling compatibility options you don’t need. BTW this answer is pretty much the same when it comes to hardening any security feature of any OS. Vendors/distributors do a good job of hardening but you might be able to lock things down just a little further.
- rlpb 3y ago
  > You have much more context about your environment- you know what you need to connect to, what needs to connect to you, and what ciphers, key length, and other configuration that you must support. Therefore if you take all that into account you might be able to optimize for security by disabling compatibility options you don’t need. As long as that's what you actually do. If instead you want a checklist to blindly execute to "harden" your system, then the grandparent commenter is correct: either your can accept that your distribution's defaults are actually good enough, or you're removing functionality such that you'll find a hurdle you've left for yourself sooner or later.
- lazide 3y ago
  If your OS distributor screwed you that badly (and a short check should be sufficient to determine if they did if the distribution is popular!) you’re deeply screwed anyway. And there is nothing post-facto you can do from within that distribution.
  - napkin 3y ago
    For two years there was an undiscovered Debian-specific vulnerability in their OpenSSL package borking the generation of keys. But your point about being screwed from within applies to this case- regenerating the keys on an affected system would not have solved the problem, until it was patched. For those curious, look up ssh-vulnkey.
    - mkj 3y ago
      Following the guide's steps wouldn't have helped in the Debian case. I reckon on average a distro ssh maintainer is more aware than an average end user following a hardening guide, even with mistakes like that one.
- e2le 3y ago
  >Changing the server key protects you against the case that whoever made the distribution did it wrong I'm unsure of ssh_host_* and it's importance, however on some hosts I manage the "ssh_host_rsa" key is only 2048 bits. Would regenerating "ssh_host_rsa" to be larger (4096 bits) not be an improvement?
tptacek 3y ago
These things (the ones you listed) aren't in fact that important to configure. What matters is that you disable password login. The rest of it is pretty performative. Small modulus finite field Diffie Hellman isn't how your server is going to get compromised. The server is going to accept the first algorithm the client proposes that's also supported by the server, which isn't going to be FFDH at all.
- j1elo 3y ago
  Ironically enough, the one most sensible thing to do, disabling password login, is not included in the linked hardening guide.
hannob 3y ago
The reasons this site recommends disabling certain algorithms are, to say the least, very specualtive. Just to give two examples: It recommends disabling diffie hellman with 2048 bit. There isn't even the slightest evidence that any attack might be possible on that size. It's just based on some policy recommendations that convert DH size to key strength and it ends up being below 128 bit. It recommends disabling HMAC-SHA1. Now, SHA1 is not collission resistant. But HMAC is not affected by this weakness. Therefore there's no real risk. Generally, OpenSSH has already improved algorithm security quite a lot over the years and everything that is remotely close to a real attack is disabled by default.
- Helmut10001 3y ago
  Is there a negative effect of applying these recommendations? On another note, this helped me solve a an issue [1], where I could not disable some weak HMAC algorithms. [1]: https://unix.stackexchange.com/q/758814/380381 https://unix.stackexchange.com/q/758814/380381
  - ahoka 3y ago
    Slower (as in less bandwidth and larger latencies) connection, using more CPU. Not sure if that makes any difference if you don’t use it for a tunnel or open a tons of connection for some reason.
- ahoka 3y ago
  I think the logic (there’s a link to an opinionated article they base their recommendations on) is the same as with TLS1.3, why wait until something gets broken? It selects a few safe choices and disables everything else. You don’t usually need to support more than two different algos, as you usually control both the server and the client.

by j1elo 3y ago

efitz 3y ago

Many (most?) releases auto generate the SSH server keys and set default configuration during OS or during SSH server enablement. Changing the server key protects you against the case that whoever made the distribution did it wrong - either used duplicate keys to other hosts, or intentionally compromised the key, or used a poor PRNG, or used a less desirable algorithm, perhaps for compatibility purposes. That is not to say that any of those things actually happened; it’s just that the most paranoid/defense-oriented view is not to trust what the OS did for you, but to do it yourself. A distro provider is incentivized to find a local optimum between security and compatibility and has no idea about your environment. You have much more context about your environment- you know what you need to connect to, what needs to connect to you, and what ciphers, key length, and other configuration that you must support. Therefore if you take all that into account you might be able to optimize for security by disabling compatibility options you don’t need. BTW this answer is pretty much the same when it comes to hardening any security feature of any OS. Vendors/distributors do a good job of hardening but you might be able to lock things down just a little further.

rlpb 3y ago
> You have much more context about your environment- you know what you need to connect to, what needs to connect to you, and what ciphers, key length, and other configuration that you must support. Therefore if you take all that into account you might be able to optimize for security by disabling compatibility options you don’t need. As long as that's what you actually do. If instead you want a checklist to blindly execute to "harden" your system, then the grandparent commenter is correct: either your can accept that your distribution's defaults are actually good enough, or you're removing functionality such that you'll find a hurdle you've left for yourself sooner or later.
lazide 3y ago
If your OS distributor screwed you that badly (and a short check should be sufficient to determine if they did if the distribution is popular!) you’re deeply screwed anyway. And there is nothing post-facto you can do from within that distribution.
- napkin 3y ago
  For two years there was an undiscovered Debian-specific vulnerability in their OpenSSL package borking the generation of keys. But your point about being screwed from within applies to this case- regenerating the keys on an affected system would not have solved the problem, until it was patched. For those curious, look up ssh-vulnkey.
  - mkj 3y ago
    Following the guide's steps wouldn't have helped in the Debian case. I reckon on average a distro ssh maintainer is more aware than an average end user following a hardening guide, even with mistakes like that one.
e2le 3y ago
>Changing the server key protects you against the case that whoever made the distribution did it wrong I'm unsure of ssh_host_* and it's importance, however on some hosts I manage the "ssh_host_rsa" key is only 2048 bits. Would regenerating "ssh_host_rsa" to be larger (4096 bits) not be an improvement?

tptacek 3y ago

These things (the ones you listed) aren't in fact that important to configure. What matters is that you disable password login. The rest of it is pretty performative. Small modulus finite field Diffie Hellman isn't how your server is going to get compromised. The server is going to accept the first algorithm the client proposes that's also supported by the server, which isn't going to be FFDH at all.

j1elo 3y ago
Ironically enough, the one most sensible thing to do, disabling password login, is not included in the linked hardening guide.

hannob 3y ago

The reasons this site recommends disabling certain algorithms are, to say the least, very specualtive. Just to give two examples: It recommends disabling diffie hellman with 2048 bit. There isn't even the slightest evidence that any attack might be possible on that size. It's just based on some policy recommendations that convert DH size to key strength and it ends up being below 128 bit. It recommends disabling HMAC-SHA1. Now, SHA1 is not collission resistant. But HMAC is not affected by this weakness. Therefore there's no real risk. Generally, OpenSSH has already improved algorithm security quite a lot over the years and everything that is remotely close to a real attack is disabled by default.

Helmut10001 3y ago
Is there a negative effect of applying these recommendations? On another note, this helped me solve a an issue [1], where I could not disable some weak HMAC algorithms. [1]: https://unix.stackexchange.com/q/758814/380381 https://unix.stackexchange.com/q/758814/380381
- ahoka 3y ago
  Slower (as in less bandwidth and larger latencies) connection, using more CPU. Not sure if that makes any difference if you don’t use it for a tunnel or open a tons of connection for some reason.
ahoka 3y ago
I think the logic (there’s a link to an opinionated article they base their recommendations on) is the same as with TLS1.3, why wait until something gets broken? It selects a few safe choices and disables everything else. You don’t usually need to support more than two different algos, as you usually control both the server and the client.