In what ways does increasing SSH host key length increase security

Question

I have read on a few guides on "how to secure SSH servers" that it is a good thing to increase ServerKeyBits from the default of 768 to 2048.

Most of these guides seem to be for the entry level/novice server admin (which I am) to quickly protect themselves from scripted brute force root ssh login attempts and things like that, and I am trying to understand the point of each security measure.

I've been reading up on how public-key based authentication works, specifically for SSH v2. I have not seen anything about the SSH server's host key being used in the process of client authentication at all, by that I mean proving that the client is trusted.

It seems to only be used to ensure that the host a client is connecting to is the same one its connected to in the past - that it's not an impostor.

I am wondering, practically speaking, why it is such a big deal to increase the host key to 2048. Does it make it harder for an attacker to somehow brute force the private host key? Even if an attacker were able to figure out the private host key, so that a client/or the administrator would be able log into the fake host, how would that benefit the attacker?

Also included in these guides is setting

PasswordAuthentication no

so the user shouldn't even be expecting to enter a password anyway. If they were so unaware of things to enter a password when they usually don't have to, wouldn't they just blindly accept a different host key anyway? Then if the attacker had the password, then what? Password authentication is disabled on the server anyway, so they still wouldn't be able to log in. From what I read, the attacker would not be able to gain any useful information from the client in the authentication process even if the client trusts the servers identity.

I feel like I am missing something major about how SSH public-key authentication works, because I don't understand why having a long host key seems so important. Does it make it harder for client credentials to be compromised somehow? What could actually happen if the private host key is compromised?

Thanks

Answer 1

There is a crucial piece of confusion in your question, which the answers here did not point out: ServerKeyBits has nothing to do with the hostkey. In fact, it is mostly irrelevant today, since it applies only to SSH protocol version 1, which has been obsolete for many years and should no longer be used.

If you’re familiar with setting up an OpenSSH server, it should also be clear operationally that an sshd configuration setting cannot by itself increase the size of the hostkey — which is sitting in a file on disk (e.g. /etc/ssh/ssh_host_rsa_key{.pub}) and is generated once and separately.

The “server key” in protocol 1 is a second RSA key — distinct from the hostkey — used to achieve forward secrecy. It is ephemeral, generated by the server on startup, replaced periodically (once per hour by default), and never written to disk. The client encrypts the symmetric session key with the server key and sends it to the server; this message is authenticated by signing it with the hostkey. In protocol 2, forward secrecy is implemented with Diffie-Hellman instead.

So, an adequately strong server key is important because if an attacker can recover it, he can read recorded SSH sessions or tamper with current ones (since he has the session encryption and MAC keys). And as a previous answer pointed out, 768 bits for an RSA key is far too short by today’s standards.

Answer 2

Short Answer: The host key is the public key of the server, and this key is used to establish shared secret (symmetric encryption key) and thus it is important that it is strong enough to stand against brute-force attack.

In detail: Firstly you need to understand how the asymmetric encryption or public-private key encryption works. Each system have a key pair comprising of private and a public key. As the name suggests, the public key is meant to be made public or in other words can be distributed to the world without any security implication, while the private key is meant to be kept secret and only the system can use it. The underlying mathematical concept with this setup is, if a message is encrypted with a public key, then it can only be decrypted with the corresponding private key and vice versa.

This asymmetric encryption is used in case of SSH to establish a secure session, which uses symmetric encryption. The key to this symmetric encryption (K_sys) is exchanged using public-private key crypto. Further all the communication between client-server is encrypted using this K_sys.

Since all the secrecy of the communication depend on the secrecy of K_sys, it is of utmost importance that the public-private key encryption is secure, as it is being used to share the secret key. And to ensure sufficient secrecy, key strength is one of the important parameter to consider. By having

Additional Information: 768 bit RSA key was successfully bruteforced in 2010 and it was predicted that with computational advances 1024 bit will become weak in upcoming decade. Hence, it is advisable to increase key strength to 2048 in near future.

Answer 3

Also included in these guides is setting

PasswordAuthentication no

so the user shouldn't even be expecting to enter a password anyway. If they were so unaware of things to enter a password when they usually don't have to, wouldn't they just blindly accept a different host key anyway? Then if the attacker had the password, then what? Password authentication is disabled on the server anyway, so they still wouldn't be able to log in.

That is precisely the point of disabling password authentication - so an attacker cannot log in if they have a user's password. In particular, you're trying to avoid allowing access to your machine via user accounts with insecure passwords, e.g. test accounts.