1. 11
  1. 3

    As an added benefit now, if one of your ssh keys ever leaks, there’s only one place to remove it from

    That’s true, but what are the chances that only one of your SSH private keys leaks? If someone gets read access to my home directory, they can copy them all.

    1. 2

      Most leaks are accidental file copies. This still protects against that.

      And if not, well, you now have a list of all the names that accept your keys.

    2. 2

      hmm, this is nice, but typically you have 1 key-pair per cloud provider (which they push upon boot). This does not work so well then

      1. 1

        This is really awesome! I’ll probably be (re)doing my keys to be like this in the next couple of days.

        1. 1

          I think this doesn’t work if you use ssh-agent, right?

          1. 1

            Does ssh-agent handle multiple keys? Yes, you have to tell ssh-add the key’s file names. But if you are security conscious and does not trust your remote machines, you must not forward your ssh-agent. You can also launch multiple ssh-agent instances, each handles a single key, then even you have to forward that single ssh-agent you don’t leak others. Though I believe the management of these suddenly becomes overwhelming. I prefer just open multiple local accounts, each used for a distinct set of projects.

            1. 1

              IdentityFile is respected by ssh-agent. I believe that even if your agent is non-standard (e.g. you’re using 1Password as your ssh agent), you can use IdentityFile with a public key file, to only offer that public key. I think you might also need IdentitiesOnly yes, based on a bit of testing; but you can set that at the top level.