How SSH achieves forward secrecy
A while back a co-worker asked me why SSH (sometimes) uses a second temporary host key in addition to the main host key. I had to think about it for a bit: it's to keep the session private even if the server's host key is later compromised.
(The clever person will notice I could have found this out just by
reading the description of the KeyRegenerationInterval
I observe that one rarely pauses to grovel through manpages when
discussing half-remembered things with co-workers.)
Public key cryptography is too computationally expensive to do all the time, so SSH sessions are actually encrypted with a random symmetric key; arranging the session key is more or less the only thing done with actual public key cryptography.
(This is common to pretty much every encryption protocol that uses public key cryptography; SSL and even GPG-encrypted email work this way.)
However, if the session key was encrypted with the server's normal host key, there's a problem. An attacker could record a boatload of SSH sessions, then later compromise the server, get its host key, use the host key to decrypt the initial protocol exchange for each session (imitating what the server did during the actual sessions), recover each session key, and decrypted all of those recorded SSH sessions at their leisure.
Preventing this attack is called having perfect forward secrecy.
In version 1 of the SSH protocol, PFS is achieved by using the second, ephemeral set of host keys. The session key is actually encrypted with these ephemeral keys, not directly with the permanent host key, and then the ephemeral keys are discarded every so often. (They could be discarded after every connection, but generating new ones is pretty expensive.)
sshd_config manpage mentions in passing, though, this only
applies to version 1 of the SSH protocol. So how does SSH v2 achieve
(perfect) forward security?
It turns out that the answer is in RFC 4251's section 9.3.7: SSH v2 normally uses Diffie-Hellman key exchange to set up the session keys, which inherently provides perfect forward security without needing a second set of host keys or anything like that. In fact it does it better than SSH v1, because SSH v2 destroys the information that would compromise the session key immediately after generating it, instead of some time later.
(This is one of those entries that I write partly to explain all this to myself, and partly because I had to go digging in RFC 4251 to find the explanation for SSH v2 so I might as well share.)