From doing some reading though it sounds like I might be wasting my time. Apparently it’s fine to have one key for an individual machine and to use that for everything.
What’s everyone else’s take on that? Are you reusing a single key or generating each time?
Sprinkle in a passphrase and now you have good MFA: something you know (the passphrase) and something you have (the private key).
Personally, I don't see a problem with re-using a key pair across multiple servers. I like to do one key pair per client device. This lets you manage server access per device. You can single out and remove just the key from a lost or compromised device without affecting the others.
OTOH, one key pair for all devices fails at this, plus you also have to worry about protecting the private key during distribution to multiple devices. A private key is best left on the client that generated it. Of course, once you hit enterprise, all this goes out the window. As they will probably have systems in place and compliance rules to follow.
Stealing passwords is much harder in comparison.
I have considered keeping encrypted keys in my password manager per-service, and decrypt+add them to my SSH agent when they're used to offer almost the same guarantees.
Er, what? The SSH keys are being generated the same way keys for web sites are under FIDO, which is to say they're random - your physical device has no idea how many keys you have, it couldn't mandate that there's only one key if it tried. It only knows how to tell if these are keys it made (otherwise presumably a different FIDO authenticator made them) and if so use them to sign you in once somebody touches the contact.
However sometimes it's practical to use the same (private) key in multiple places. I do this for access to low-risk stuff like ssh access to my raspberry pis. I wouldn't ever move a private key around for anything remotely dangerous though.
It’s really very minor and ssh itself should warn that the servers fingerprint changed.
You can't realistically MITM SSH because you will have a session mismatch. You may be able to convince a naive visitor (coming to some.machine.example with no prior contact, and not using either certificates, or secure DNS protected credentials to verify the identity of the machine) that you're some.machine.example but you can't successfully splice this to a connection with the real some.machine.example if they use public key login.
The reason is, during connection you persuaded the client that you are some.machine.example, but to do that you needed to make up keys since you don't know the real keys for some.machine.example. However the real some.machine.example does know its keys and they're different. The credentials the victim client gives you only work for your keys, they won't work for the real some.machine.example keys, and the client has no reason to present you with credentials that would work for the real some.machine.example, so you can't authenticate to the real some.machine.example as them.
If something more robust is needed, ssh certs and principals can be used.
Some use Pam modules to require 2nd factor too.
Try thinking of SSH pub keys as identities or usernames and you are more on the right track.
I tend to have 1 pubkey per thing I care about, so 1 per github account, 1 per gitlab account, 1 for work, etc.
It's automatable and one less thing to worry about.