1Password for SSH was shared with the world last month. I have been using it since it was available for internal beta. I knew it would improve my endpoint security. I didn’t expect it to change the way I generated, stored and used SSH keys the way I work.

Let me take a step back.

The first time I used SSH, I connected my college’s global lab linux server with PuTTY. I used a username and password to authenticate and never really appreciated the magic that made it all work. It was a step away from the familiar world of FTP and RDP.

SSH later became an integral part of my developer experience when my job switched from Subversion to Git. I was a Jr. Developer at the time and struggled to generate an SSH key. Another developer on the team generated an RSA key pair for me and shared it on a thumb drive. It was some years later before I realized this was less than ideal.

Eventually, I fell into a routine. I would get a new laptop, generate a private key – sometimes I would even use a passphrase – and upload the new key to all the services I used (GitHub, VPS, etc.). I used the one-key-per-device pattern and repeated the process for my phone and other devices. Occasionally, I’d pull a device from cold storage for something I forgot about.

The problem was that each SSH key represented one of my devices; it had no purpose attached to it. I used the same keys for work, open source contributions, file servers and a lot more. When I unlocked a key for one use, I unlocked it for all uses.

1Password for SSH has entered the chat

The 1Password SSH Agent has a stricter authorization model than the OpenSSH Agent[1] defaults[2]. Instead of a key either being available or unavailable, a key has an authorized session. An authorized session consists of the key pair and either a terminal session or application. I wanted to be able to deliberately authorize a set of actions for my current context (e.g., work or open source).

Thus, a new way of working.

I generated a new key pair for each of my use cases. 1Password in the browser made this really easy by autofilling the new key in the GitHub and Gitlab public key forms. Now, when it’s time to get to work, I open my terminal and run a git fetch. 1Password prompts for my fingerprint and I approve the usage of my Work SSH key.

I’m not prompted again while actively using my laptop. When it’s time to switch to an open source project, I’m seamlessly prompted for my GitHub key.

A little later, when I need to update my blog, I pop open a new terminal tab and start an SSH session. I forward my SSH Agent with ssh -A so that I can perform a git pull while I’m there[3]. When I’m done, I exit the terminal session, deauthorizing it from the 1Password SSH Agent.

Now, generating SSH keys is no longer part of my new device flow! All of my SSH keys are saved in 1Password and synchronized across my devices.

I’m really excited for Git’s recent addition of commit signing with SSH keys. It already works with 1Password SSH and I can’t wait for GitHub and Gitlab to support verification!

[1] SSH agent restriction looks really cool! ↩︎

[2] Similar functionality is available with ssh-add -c. ↩︎

[3] Eventually I’ll get around setting up a GitHub Action. At least, that’s what I tell myself. ↩︎

This post originally written by K.J. Valincik, Senior Staff Developer at 1Password.