> What's the point of having different ssh key per server?
I do have some use-cases where I use different ssh-keys per server/cluster:
- Setting up client's machines allow me to nuke the keypair when work is done and I no longer have access. Customers trust me to do this - they trusted me to set up their machines already.
- Belonging to different projects: so that when the project is finished, handed over or closed down, I can safely delete all keys associated with that, knowing for sure I'm not deleting keys that I did need after all.
- Having different levels - testing these levels. I set up servers in a way that there's sysadmins who have root/sudo, and `deploy` users that can only deploy apps (e.g. capistrano, ansible, k8s and so on) and maybe `sudo systemctl restart my-app` and/or read certain /var/log/some-log. I want to be sure that something does/does not work because of the correct keys, and not because one of the 12+ keys in my ssh-agent happens to be used instead.
So, in my case, I do have a lot of ssh-keys that I juggle with.
I wish there were just a version of ssh-agent/ssh-add though, with better UX. Looks like maybe viking is that?
People should generate at least a single ssh key per client device. (On Userify, rotating your key is just a matter of pasting the new public key into your keybox in your dashboard.) One per client device will let you revoke/rotate only that key when it's compromised. This also helps keep you from copying the private key somewhere else (which you should never do).
It does look like this wants to be a replacement for ssh-agent/ssh-add; also check out GNU keychain by Daniel Robbins, which is in most distro repos.
(blatant plug - we actually developed Userify for these three use cases, especially on cloud instances with constantly changing IP's)
I do have some use-cases where I use different ssh-keys per server/cluster:
- Setting up client's machines allow me to nuke the keypair when work is done and I no longer have access. Customers trust me to do this - they trusted me to set up their machines already.
- Belonging to different projects: so that when the project is finished, handed over or closed down, I can safely delete all keys associated with that, knowing for sure I'm not deleting keys that I did need after all.
- Having different levels - testing these levels. I set up servers in a way that there's sysadmins who have root/sudo, and `deploy` users that can only deploy apps (e.g. capistrano, ansible, k8s and so on) and maybe `sudo systemctl restart my-app` and/or read certain /var/log/some-log. I want to be sure that something does/does not work because of the correct keys, and not because one of the 12+ keys in my ssh-agent happens to be used instead.
So, in my case, I do have a lot of ssh-keys that I juggle with.
I wish there were just a version of ssh-agent/ssh-add though, with better UX. Looks like maybe viking is that?