28

SSH protocol 2 allows you to use DSA, ECDSA, ED25519 and RSA keys when establishing a secure connection to a server. (Keep in mind for this question that I'm only familiar with the procedure and capabilities of RSA, and can't speak for the other methods)

What confuses me, is according to man sshd, Diffie-Hellman is used for the key exchange:

For protocol 2, forward security is provided through a Diffie-Hellman key agreement. This key agreement results in a shared session key. The rest of the session is encrypted using a symmetric cipher...

This leads to two questions:

  1. Where does the RSA key come into play if it isn't used during the key exchange?
  2. Why is a second protocol (in this case, Diffie-Hellman) required? Why not just use the client's RSA public key to encrypt the session key on the server, and send it to the client?
IQAndreas
  • 6,845
  • 10
  • 35
  • 53

1 Answers1

35

  1. The host key is used to sign the Diffie-Hellman parameters. It is used during the key exchange; RSA is a signature algorithm as well as an encryption algorithm. From what I can tell, the client key (in authorized_keys) is not used in key exchange at all; it's only used after key exchange to sign a particular message and prove the client has the private key (one side of DH parameters being signed is enough to prevent a MITM, because the attacker can't impersonate both client and server; it's easier to make the server always have to have a keypair than make the client always have to have a keypair).

  2. The way SSH uses DH is as an ephemeral algorithm: DH parameters are generated for individual sessions, and are destroyed as soon as they're no longer needed. The only thing the long-lasting keypair is used for is authentication. This gives forward secrecy: stealing the private key doesn't let you decrypt old sessions.

    If RSA was used to encrypt the session key, then someone who recorded that session, buys the SSH server years later after it's been decommissioned, and obtains the private key off its hard drive can use that to decrypt the session key, and use that to read the entire communication. If RSA is used to sign DH parameters, then the only way to exploit a stolen private key is in a man-in-the-middle attack, and that can be foiled by the server operator changing the key and telling all his users about the changed keys. With ephemeral key exchange, nothing needed to decrypt a recorded session is stored any longer than it has to be.

    This is also a configuration being used increasingly often for TLS sessions (there, where certificates have expiration dates, a private key doesn't even strictly have to be kept secret after its expiration because it shouldn't be possible to use it in a man-in-the-middle attack; it is, because users will ignore expired certificates, but you can see why ephemeral encryption is nice).

cpast
  • 7,413
  • 1
  • 31
  • 35
  • In summary, SSH uses RSA to establish an initial secure, authenticated connection (ie: the server trusts the key and the client must have the key in order to connect), and then uses Diffe-Hellman to establish an ephemeral (ie: one time) key to establish forward-security. Diffe-Hellman doesn't work without having a secure and authenticated connection because a MITM could easily intercept communications. – Naftuli Kay Dec 26 '14 at 21:13
  • I think "secure" here isn't actually needed for DH parameters - all you need is the authentication, to prevent tampering by an active attacker. DH is secure against passive eavesdroppers, it's just trivial to MITM without authentication. – cpast Dec 26 '14 at 21:21
  • 1
    @NaftuliTzviKay: Actually, AIUI, it's the other way around. First, Diffie-Hellman is used to negotiate an ephemeral shared key between the client and the server; then, RSA (or DSA or some other signature algorithm) is used by the server to sign the key, so that the client knows that the party they just negotiated the D-H shared key with is the server and not some middleman or impostor. The point is that, even in the presence of active MITM attacks, D-H lets you negotiate a shared key with someone -- it just doesn't tell you who that someone is. An RSA signature solves that part. – Ilmari Karonen Dec 26 '14 at 21:23
  • 2
    Correct. You need a MITM who can write to cause problems with DH. – Naftuli Kay Dec 26 '14 at 21:23
  • I think it's actually different between host and client keys. According to the RFC, the host key is used to sign the server's DH parameter; that's enough to prevent MITM if the client checks host keys. Client authentication is done after the key is negotiated, signing some session-specific string to verify that the client has the given private key. – cpast Dec 26 '14 at 21:41
  • Nitpick: DH keys are per-session aka ephemeral; parameters can be and usually are long-term. – dave_thompson_085 Dec 28 '14 at 14:51
  • In your first paragraph: what is the host key regarding client-server and public private key? Refers host key to the client public key stored on the server in authorized_keys? And: it's easier to make the server always have to have a keypair than make the client always have to have a keypair. With ssh the server never has the private key, but ssh checks the corresponding private key on the client. So the client has the key pair, the server has a copy of the public key. – Timo Dec 14 '22 at 09:30
  • 1
    @Timo The host key is a separate keypair stored on the server in /etc/ssh/ and used by sshd to authenticate the server to the client. – cpast Dec 14 '22 at 14:13