I think this is a bad idea for users. I don't think SSH keys are things you should share across machines in a password manager. If you have two devices, then you should have two keys (though this is the subject of some debate; see [0]). Using the 1Password SSH agent encourages people to have "one" SSH key across devices, which means that any leaks will disproportionately impact them.
It's unfortunate, because there is some real innovation around the per-application usage permissions:
> 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.
If an organization wishes to solve the SSH pubkey distribution problem (the main reason one would copy a private key across machines), then they should use SSH certificate authorities like [1]. In fact, I think that would be a far more interesting 1Password product—HashiCorp Vault could use some competition for this kind of use-case.
> I don't think SSH keys are things you should share across machines in a password manager.
While I agree with the first half of your statement (don't share SSH keys), I cannot agree with the second (don't put SSH keys in a password manager).
For my home use of 1Password, I absolutely want to keep backups of my SSH keys in 1Password. Because, in general, there's exactly 1 SSH key which can get into my cloud instances, and I've had enough laptops die suddenly that I'm not willing to risk getting locked out by not having a backup.
You could say "well, just have a second device with backup keys" but again for home use, why would I buy another laptop just for that? Or maybe just "well keep an offline backup of your keys". Sure. In 1Password. Where I keep pretty much all of my sensitive credentials and info.
> Using the 1Password SSH agent encourages people to have "one" SSH key across devices, which means that any leaks will disproportionately impact them.
Eh. IMO, people who are inclined to use 1 key across machines are going to do it, no matter the process. I doubt this feature is going to make that any worse. But I guess we shall see.
I'll concede that it's not nearly as crazy to share keys across devices for home use or low-risk things. I must admit I was speaking mostly from an enterprise perspective.
I could see this eventually being built into 1Password's Secrets Automation product which can sync to each user's 1Password client. It allows the use of Vault for a backend so now that SSH Keys in 1Password are a thing it wouldn't be out of the realm of possibility to have Vault generate short-lived per-user SSH certificates that are automatically rotated into the user's 1Password vault.
It's unfortunate, because there is some real innovation around the per-application usage permissions:
> 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.
If an organization wishes to solve the SSH pubkey distribution problem (the main reason one would copy a private key across machines), then they should use SSH certificate authorities like [1]. In fact, I think that would be a far more interesting 1Password product—HashiCorp Vault could use some competition for this kind of use-case.
[0]: https://security.stackexchange.com/a/40061
[1]: https://www.vaultproject.io/docs/secrets/ssh/signed-ssh-cert...