Ah neat, the app exposes an ssh agent socket: export SSH_AUTH_SOCK=~/.1password/agent.sock So you would essentially replace Keychain, Gnome-keyring, or the vanilla SSH-agent with 1password. Very nice solution.
What is the benefit over ssh-agent?
1Password for SSH and Git (Beta)
81–90 of 406 posts
Re: 1Password for SSH and Git (Beta)
#82Earlier quoted context omitted.
Doesn't this give 1Password root on the universe? That's a general theme I see with all this SSO stuff. You have a few companies with root on the universe. Am I weird that this concerns me?
The data that 1Password stores on their end is encrypted with your personal passphrase. So they can't see it even if they want to. Unless their local client was compromised (not impossible - but if your local is compromised you're in trouble regardless), even if someone hacked them and stole their data, they would not have your clear-text info. It's everyone's choice to make but I am personally OK with this security/…
> The data that 1Password stores on their end is encrypted with your personal passphrase.
For now. What happens when they eat enough of the market and displace enough other tools that the government says "Ok, now MitM the encryption." All they would need to do is push an update and re-encrypt the first time you unlock it. Now, this has always been true, but it's not on your servers and source repos yet, right now it's sandboxed.
How about internet outages? Service outages? Sure, local cache, but that cache expires.
I love PW managers, even cloud ones, but I wouldn't tie on directly to my local login and auth infrastructure to the exclusion of other local options.
I have autofill turned off because it can fill into nefarious forms if you're not careful. And I copy and paste from my pw manager into my terminal when required, because again I don't want it automatically being helpful when I want to be careful.
Re: 1Password for SSH and Git (Beta)
#83Earlier quoted context omitted.
I use a handful of keys. Thing is, your secret is never shared with the server. Just the public key bits. Passwords are stored (hashed) on the services. Totally different threat models. With your public key the biggest risk is someone tracking what you are up to if they compromised multiple services/servers you use.
Not really. Do you think the ssh client machine is easier to secure than the ssh server? (It isn't.)
It objectively is since I never transmit the private key bits to the server. Passwords usually require the whole secret be blasted about the Internet (albeit encapsulated in TLS, usually).
Re: 1Password for SSH and Git (Beta)
#84Ah neat, the app exposes an ssh agent socket: export SSH_AUTH_SOCK=~/.1password/agent.sock So you would essentially replace Keychain, Gnome-keyring, or the vanilla SSH-agent with 1password. Very nice solution.
What is the benefit over ssh-agent?
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.
Re: 1Password for SSH and Git (Beta)
#85I’ve been treating SSH keys in the same way I would a password. Each service gets a new key generated for it. From doing some reading though it sounds like I might be wasting my time. Apparently it’s fine to have one key for an individual machine and to use that for everything. What’s everyone else’s take on that? Are you reusing a single key or generating each time?
I do one per machine, usually. That way if the machine is lost, it’s easy to revoke the keys.
Re: 1Password for SSH and Git (Beta)
#86Ah neat, the app exposes an ssh agent socket: export SSH_AUTH_SOCK=~/.1password/agent.sock So you would essentially replace Keychain, Gnome-keyring, or the vanilla SSH-agent with 1password. Very nice solution.
Not really into replacing vetted, well tested open source software with a proprietary app with cloud storage.
Then don't? It's not like anyone is going to force you into using 1password.
Re: 1Password for SSH and Git (Beta)
#87Earlier quoted context omitted.
Not really into replacing vetted, well tested open source software with a proprietary app with cloud storage.
To each their own.
Not really. What is the case for not using well vetted best practices and replacing those with an unvetted proprietary solution? What problems does 1PW solve that necessitates taking on such risk?
We're not talking about social media PWs. ssh keys are not something to add risk to, eh.
Re: 1Password for SSH and Git (Beta)
#88I’ve been treating SSH keys in the same way I would a password. Each service gets a new key generated for it. From doing some reading though it sounds like I might be wasting my time. Apparently it’s fine to have one key for an individual machine and to use that for everything. What’s everyone else’s take on that? Are you reusing a single key or generating each time?
IMO, an ssh public key is not a password and shouldn't need to be treated as such. The public key portion is public. When you generate an ssh key pair, its like making both a lock and a key, then giving the lock to a server and saying "use this lock on my door". This lock can only be opened with your key, and can only be picked when your encryption algo of choice (ed25519 for me) gets obsoleted.
Sprinkle in a passphrase and now you have good MFA: something you know (the passphrase) and something you have (the private key).
Personally, I don't see a problem with re-using a key pair across multiple servers. I like to do one key pair per client device. This lets you manage server access per device. You can single out and remove just the key from a lost or compromised device without affecting the others.
OTOH, one key pair for all devices fails at this, plus you also have to worry about protecting the private key during distribution to multiple devices. A private key is best left on the client that generated it. Of course, once you hit enterprise, all this goes out the window. As they will probably have systems in place and compliance rules to follow.
Re: 1Password for SSH and Git (Beta)
#89Earlier quoted context omitted.
The data that 1Password stores on their end is encrypted with your personal passphrase. So they can't see it even if they want to. Unless their local client was compromised (not impossible - but if your local is compromised you're in trouble regardless), even if someone hacked them and stole their data, they would not have your clear-text info. It's everyone's choice to make but I am personally OK with this security/…
> The data that 1Password stores on their end is encrypted with your personal passphrase. For now. What happens when they eat enough of the market and displace enough other tools that the government says "Ok, now MitM the encryption." All they would need to do is push an update and re-encrypt the first time you unlock it. Now, this has always been true, but it's not on your servers and source repos yet, right now it'…
Note that, to my knowledge, 1Password's local cache never expires, not even after you've been removed from the 1Password account on the cloud side.
Re: 1Password for SSH and Git (Beta)
#90Ah neat, the app exposes an ssh agent socket: export SSH_AUTH_SOCK=~/.1password/agent.sock So you would essentially replace Keychain, Gnome-keyring, or the vanilla SSH-agent with 1password. Very nice solution.
What is the benefit over ssh-agent?
access to your ssh keys on any machine