As you may have heard, Github changed its RSA SSH host key today, because the private key had been exposed (apparently briefly) in a public Github repository. As a result of this, a lot of people got scary looking SSH warnings. One reaction people had to this was to note that Github could have avoided these warnings if it had used OpenSSH host key rotation to provide a second RSA host key in advance to prepare for the rotation. However, there is one little issue with this, which I alluded to on the Fediverse:

One thing Github is doing today is making people extremely aware that the prior Github RSA key is now invalid. This is a good thing with the key being presumed compromised, and one I don't think you can get with ordinary OpenSSH key rotation.

(I first saw the key invalidation issue pointed out in someone's Fediverse post, which I can't find now.)

This is something worth repeating: key rotation doesn't give you key revocation, and the two are different things. Key rotation gets people to accept and use a new key; key revocation gets them to not accept the old one. Of course if you revoke the current key you generally want people to rotate into using a new one, but you can want people to rotate into a new key without any particular revocation of the old one.

Broadly, key rotation by itself is a precautionary measure (much like periodic password changes) or a way to get people to upgrade to a better key (for example, to move from a 1024 or 2048 bit RSA key to a bigger one, or to switch key types). Key rotation doesn't actively force people to stop accepting the old key (although if the old key has an embedded expiry, it may fall out of validity on its own), it just enables them to also accept the new one so some day you can switch to only using the new one. If your key has actually been compromised, passively switching away from it isn't sufficient; you need to get people to actively stop accepting and using it. You have to assume that your old key in the hands of an attacker who can still use it, even if you don't, which lets the attacker target anyone who'll still accept the old key.

What Github has done isn't actual revocation (as Ewen McNeill noted); numbed by one alert, people could be coaxed to accept another alert and go back to the old key. Or an attacker could target people who haven't hit this yet (or haven't updated their keys) and feed them the old key, which they'd accept without warnings. But by making this a noisy event, Github has probably come as close to actual SSH key revocation as SSH allows.

(That SSH doesn't have anything better than this for key revocation of ordinary host keys is not really its fault. Github is using SSH in a situation that is really a better fit for the server authentication properties of public web TLS.)

PS: If an attacker can use the Github situation to get people to accept a second 'remote host identification has changed' key change for Github, they don't actually need Github's old private key; any new key will do.