Not really into replacing vetted, well tested open source software with a proprietary app with cloud storage.
> The standard OpenSSH agent (ssh-agent) that comes preinstalled on most systems requires you to add keys to the agent (ssh-add) every time it launches. After you've added your keys, any process can use any SSH key that the OpenSSH agent is managing. It is then up to you to remove those keys when they're not needed anymore.
> The 1Password SSH agent uses a different approach. 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.
> When your turn on the SSH agent from the 1Password preferences or settings, every eligible key is automatically available to use for SSH, but your private keys will never be used without your consent.
Unknown vulnerabilities won't need your consent.
We're not talking about social media PWs. ssh keys are not something to add risk to, eh.
I mean, 1Password already stores my credentials for the AWS console, Cloudflare, Netlify, GitHub, et al. I’m not sure adding my commit keys to that pile is dramatically increasing my exposure.
A place I worked before would store SSH keys for build machine base images (AWS AMIs) in 1Password. It wasn't worth the trouble trying to setup SSO since the machines rarely needed accessed and only by a handful of people to troubleshoot/manage them.
It's also common to share credentials when you're working with small SaaS that don't support multiple users or SSO. In addition, sometimes business integrations will have fixed credentials (like the SSH key to upload reports to a business partners SFTP server). People still need access to the keys for troubleshooting and debugging.
I don't think running a Userify daemon on the server is better than a private key in 1Password. At least with the private key approach, you can layer on network access restrictions (firewall rules or VPN). Userify would need to create an outbound connection to its control plane to manage keys
You swap "someone could steal my private key from SaaS" with "someone could upload an additional key to SaaS" which I guess just helps if you're reusing keys for unrelated systems?
I think Userify could potentially increase auditability by limiting key sharing but I don't see it actually increasing security assuming you can revoke/rotate shared keys.
If 1Password was ever compromised, the attacker could use my private key to log into any server that I have access to at any time forever, and in fact I won't even know! But, if Userify is compromised, then the attacker can only deploy their OWN public key but my private key is still safe.
This means that if 1Password is compromised, ALL private keys are compromised forever. If Userify is compromised, the compromise only lasts for as long as the attacker is actually logged in as you, and the prize for the attacker isn't getting your key (because it's public already), but only that they can deploy their own public key (and that produces a notification).
So, you're right in that you still have to place some degree of trust in a third party SaaS, but the simplicity of Userify's model and narrow scope which minimizes access to any secret material is very appealing because it's very easy to understand and audit. Userify is about as close to Zero Knowledge as you can get for an SSH connection.
And, if that's not enough, I can just buy my own Userify Express server and close it off on my own private Wireguard network or VPC and never let the outside world anywhere near it.
Right, this is only a problem if you don't have another form of key and don't have login auditing
With access to Userify, an attacker could upload a key to any server anywhere and still have access.
In the original post, I mentioned we already had an easy way to rotate keys via automation. We also had CloudTrail alerts and AWS Config alerts around port 22 security group rules (they were closed by default).
Sure Userify provides a lot of these things like key management and audit trails but my original point was it's silly to worry about storing private keys in SaaS when you use SaaS for other authentication and authorization anyway.
So again I'll ask: what case does 1PW make to deviate from those?