The solution to that is to use the IdentityFile directive in your ~/.ssh/config with username / hostname expansion. I use:

    Host *
        # Disable SSHv1
        RSAAuthentication no

        # Only use a key explicitely provided by an IdentityFile directive
        IdentitiesOnly yes

        # %h expands to the hostname, and %u to the username
        IdentityFile ~/.ssh/%h/%u.key

This ensures that at most one key is used, and prevents me from having to modify my config every time I generate a key for a new host.

The point remains, there isn't much benefit to using a different key per host. What attack vector is this extra effort protecting you from?

Awesome, I did not realize you could use filename templates for SSH keys. Thanks!

I think you're supposed to configure SSH to use the right key without trying them all in your ~/.ssh/config

> What attack is this even preventing

I think the thought is the security practice of compartmentalization. If you lose the private key you use for GitHub, Amazon, DigitalOcean, your home servers, etc... you've effectively given root away.

Now if my laptop is compromised, it doesn't matter if I have one key or ten, I've lost them all. But if there's something heartbleed-esque that allows individual private keys to be stolen when pushing commits to GitHub, I've at least isolated damage to my GitHub account.

But the private key is (of course) never sent to GitHub, so it's hard for me to imagine what kind of vuln this would help with. I can think of a few, but they're odd:

1. Some sort of remote memory leak that leaks the current private key, I guess.

2. Some sort of relay attack where you can impersonate the legit host.

In both of these cases, it seems like at a minimum you would need to, on the client, set up an ssh config that limits each identity to each host so as to prevent the client from trying each key in sequence (and thus potentially exposing it). That's a huge hassle!

So I guess tl;dr: I can think of a few cases where this might be useful, but if you're always SSH'ing from the same laptop, this step can probably be pretty far down your list of things to do.

> What attack is this even preventing - that someone will be able to reverse ssh public keys and get the private? A better approach is to generate a unique key per client so that if you lose access to a device you can remove only its public key.

I don't think this is about security. Just about privacy.

Some people don't like that they can be identified by their public key. eg (I think) github allows public viewing of a specific users public key, and that allows other services you use with your public key to know your github account etc.

It's not a mainstream privacy concern, but there are some privacy oriented people that worry about it.

Why not use 'ssh -i key_file user@domain'?

Should only use the specified key file then, AFAIK, without doing the cycling you mentioned.