Where is the ssh-agent reading your private key from? If from ~/.ssh/, you're just one "npm install" away from the key being exfiltrated by a compromised package. If the private key is on your Yubikey, you're already good. The 1password agent will provide a good hardwareless method of keeping your private keys off the local filesystem, and it'll sync between your devices too.
> you're just one "npm install" away from the key being exfiltrated
It's not as easy as that if your private key is protected with a passphrase, which IMO ought to be the default option.
I am amused by the rationalization going on here, though... taking extra steps to secure your SSH private key because you might "npm install" something bad. There's nothing wrong with enhancing the security of your private keys through dongles or TPM chips but it's a lot better to attack the root of the problem: just don't run "npm install" (or similar untrusted code) in an environment that you don't want to get pwned.
My day job has me working with javascript packages but I don't have npm installed on my system, and never will. All of my work with npm happens inside docker containers. This offers many workflow advantages besides a layer of security.
Just because I happened to be dealing with this today (on Windows with WSL2 but same rules apply) I'll make a comment.
The issue I ran into was due to Docker for Desktop binding the local filesystem into the devcontainer running in a WSL2 VM.
The solution to this is to instead use a named volume in your docker-compose.yml and in your Dockerfile copy the files from your working directory into your devcontainer.
This provided an incredible improvement in the performance of using devcontainers in vscode. The one big drawback to this approach that I've run into is needing to make sure I commit and push my code to a git repo when I'm done working as there's not a copy stored on my local machine.
Your ~/.ssh/ private key is not readable by normal users since it's encrypted, so that isn't going to work.
The main security benefit is here:
> 1Password will ask for your consent before an SSH client can use your SSH key. Because of this, there's no concept of adding or removing keys like with the OpenSSH agent.
This prevents SSH agent hijacking, requiring either a social engineering attack to bypass or a privesc.
A process can not dump the memory of another process if those processes are executing under different users, or the process performing the dump is root.
On many OS's there are even more strict restrictions, where within a user a process can only dump the memory of processes that are its direct descendants.
they would have access to the socket not the key, sure a very elaborated attack can probably figure out how to exfiltrate a lot of things (since they have already compromised the host) but for most, if they don't see things in ~/.ssh they would just go away and figure out another host to exfiltrate keys
Other commenters have mentioned sync, which is absolutely nice, but one other advantage is shared keys.
Obviously it's not ideal to share SSH keys, but lots of teams will share the default EC2 keypair for example. This makes it much easier to pop that key into 1Pass, share it with the team, and easily get everyone into the box.
And, frankly, 1Password gui is much more user-friendly than other SSH agents. Personally, I'll stick with the tried and true OpenSSH agent, but I know many will be attracted by this feature.
Point of order: afaict currently keys can be put in a shared vault but only keys in a private vault can be accessed by the agent. So the workflow would be everyone copies the shared keys into their private vault.
Isn't this an anti-feature? The ability to revoke an SSH key specific to a stolen laptop from a server or your Github account seems like a benefit. Using the same SSH key on every machine is a downgrade.
On the other hand, the ability to manage access to shared keys is really nice.
But why are you "rotating" keys? Most of the reasons people give involve unnecessary exposure of the private key material, which is exactly what you're encouraging by having 1password keep these keys instead of them living on individual hardware.
You may notice they aren't called "Fun size sharing keys" or "Family pack keys" but instead "Private keys" because of that word "Private".
You don't need to wait for people to "exit the company". Sharing private keys was wrong, invalidate those keys. If somebody else knows your private key it isn't private any more. Get this stuff right and rotating keys is unecessary, get it wrong and rotating keys can't help you.
Has anyone compared the new 1password GUI for ssh keys to the Userify one, esp for a team? The userify one is only for SSH keys, but it seems great for safely managing public keys and leaving the private keys safe on our dev laptops (you can put in more than one key so a user can just disable one key at a time, and then it also has a great feature of actually killing all remote sessions when you remove the user account across all the servers -- haven't seen anything else that can do that.) The UI is perhaps a bit simplistic but it seems to do the job.
The cloud syncing, I suppose. If you migrate devices frequently and have more than a single ssh key, it might make sense to log into 1Password instead of trying to securely copy your private key from one device to another.
It does seem like a weirdly specific use-case. I wonder if they're trying to instead target people who need to use ssh keys but aren't comfortable generating or managing them on the command line. With Github requiring SSH keys for command-line pushes, this is probably a growing demographic.
