Granular SSH Management

Something I’ve always thought was important, but never found many great resources on was managing IdentityFiles with ssh. The Manpage explains most of it, but in usual Linux Documentation fashion it’s about as fun to read as a phone-book, thus this crappy blogpost. It’s not difficult, just annoyingly lackluster in terms of management documentation online. For the Longest time I had no idea that there was even a ~/.ssh/config file, let alone that you could specify separate Identities. In fact for an embarrassingly long time my config looked like this:

IdentityFile ~/.ssh/keys/id_rsa_GitHub
IdentityFile ~/.ssh/keys/id_rsa_GitLab
IdentityFile ~/.ssh/keys/id_roving
[...]

Which, if you don’t know, will attempt to connect with id_rsa_Github, then Gitlab, then roving… on and on until one worked or it ran out. This actually worked too, until I started using services that limited login attempts. Who knew.

The importance (to me) was pretty clear, using a dedicated ssh key for a service, or group of services, allows for better control over what has access to what, and if for “some reason” you manage to leak only one of them, other services aren’t compromised. Not that I’ve ever accidentally posted my private key when someone asks for a pubkey for allowing me server access. I’d never do something like that.

A basic configuration section in ~/.ssh/config might look something like this:

Host GitHub
   HostName github.com
   Port 12345
   User git #Defaults to your username on the current machine
   IdentityFile ~/.ssh/id_GitHub

Technically speaking the only separators between Sections is Host <something> The tabbing and spacing doesn’t matter. Personally I put the tabs for the sake of visual separation.

Using it

As an example of where this would be useful, I deploy and update the server using rsync, (which is pretty nifty on it’s own and I should do a post talking about it) and when I want to update all that’s needed to utilize the config, is use something:/var/www instead of hugo@pedanticmonkey.space, despite using a different user to log in/administrate the entire VPS the Hugo config works great, without the need for a password and using a separate key, if the hugo user’s private key were to be leaked accidentally I would still be secure on my other platforms, indeed my “admin” account would also remain secure (though obviously the VPS wouldn’t)