[Edited: This used to begin "However SSH keys enjoy forward secrecy" but on more consideration that's the wrong way to look at it anyway]

The only role your SSH key plays (which is why you can use Ed25519) is to make signatures. So, if the government discovers next Thursday how to break my archaic RSA key, they don't magically get to read transcripts of SSH sessions they recorded, they only get some sort of attack that could help them to impersonate me on fresh connections after Thursday.

Essentially the authentication step goes like this:

You: I know the private key corresponding to this public key 123456, does that help?

Server: (Examines authorized_keys list) That would work, prove you know that key

You: <Signature of SSH setup transcript using private key>

Server: Welcome southerntofu

All this is happening inside an encrypted session. Your client (and remote servers) automatically negotiate the safest mutually intelligible session key agreement and encryption to set that up, independent from stuff like your personal keys.

I think the same thing about SHA-1. It is possible to generate a collision with it, but it is costly, inefficient and practical.

If you design software, then yes you should put mechanisms in place to replace older and less secure ciphers with new ones, and prefer and limit the ones you chose for some who are considered safe at the moment. But I don't think we should put red flags all over a cipher or a hashing functions because someone with unlimited resources and money managed to fool it once.

The aspect here is that we have zero evidence that the next breakthrough would allow the cracking of 2048 bit RSA and not, say, 4096 bit RSA. Chances are, any such breakthrough would allow a more general solution. See quantum computing for an example where this would be true.

The inherent uncertainty of cryptography seems to cause people to want to do something, anything, in an attempt to decrease the uncertainty, even if there is no rational reason behind the approach.