SSH public keys

[brainstorm]

Offer the possibility to publish SSH keys to be used by third parties. Perhaps unverified, provided that other services like DNS, twitter and GitHub have been approved first.

[cweagans]

+1 -- this is definitely a good feature. There's gotta be some way to verify this, too. Perhaps after uploading a public key on the website, you can have users attempt to SSH into a server as a user generated specifically for that verification and run a verification program (perhaps passing a verification token into the program as an argument).

I would definitely use this feature. Right now, the process is not very nice.

[cweagans]

As a separate, but related feature, it would be cool if the keybase command line program would allow you to download an SSH key and add it to the current user's authorized_keys file. This would make managing those key files really nice :)

[brainstorm]

Killer feature!

[malgorithms]

we're very interested in SSH here, too. And, more generally, this is a shared problem with other kinds of key signing. (Bitcoin addresses, for example)

Some considerations we talk about:

• it would be nice if signing went both ways; in the SSH case it would be nice if given an SSH key you'd know who owns it. this requires signing a statement with the key, stating which Keybase user you are. Not just signing the key with your PGP key.
• how do we deal, for convenience, with either key portability or multiple SSH keys per user? I think many users have the workflow that they generate a new key pair with ssh-keygen every time they set up a new machine. If so, do they need to run a keybase command on each of these machines, and then, what gets added to authorized_keys? all of them?
• should there be some kind of PAM module? (let keybase user X login to this machine)

Lots of stuff to think about here. But yeah, we really like the idea of finding a way of solving "Let user X onto this machine"

[brainstorm]

@malgorithms,

What about just doing what Github does?: https://help.github.com/articles/generating-ssh-keys

$ ssh -T git@github.com

Therefore:

$ keybase ssh --test

Would connect to brainstorm@keybase.io in my case and verify whether I can login with the public key.

Some keybase.io-side logic would have to be put in place to handle the multiple public keys issue... I would just copy GitHub's profile forms for that, they are simple and your target people are used to it already :)

I think the last point is a bit overkill, keep the client simple, let the users hack around it.

[zQueal]

$ keybase ssh --test Would connect to brainstorm@keybase.io in my case and verify whether I can login with the public key.

Awesome idea.

[exabrial]

It would be really neat to publish my public ssh key on Keybase. Then, a PAAS system could pull my keys down from keybase to use as an initial secure login.

[nehalecky]

+1: Just landed here after looking for the same feature. This would be an awesome addition.

[ghost]

Big 👎 to unverified SSH public keys being allowed.

So what does an SSH key proof entail? The keybase ssh --test scheme is clever, but is a much weaker proof than the others.

Twitter, GutHub, DNS, et al proofs have the advantageous properties of external verifiability and resistance to 3rd party interference. A proof made using the keybase ssh --test scheme I cannot verify myself and requires me to trust keybase.io exclusively.

Furthermore, those proofs are primarily identity, e.g. "this is me, this also me," whereas SSH public keys enable access – typically CLI access – to a host. An SSH pubkey proof must be at least as strong as the others.

[grawity]

SSH keys are in the end just asymmetric keypairs used for signing server's challenges. The client could sign a proof in the same way, perhaps even using ssh-agent.

On the other hand, that would mean implementing a lot of key formats and/or agent protocols. (OpenSSH's new bcrypt-based format and the old "raw parameters" one, PuTTY's PPK, etc. × RSA, DSA, ECDSA, Ed25519, etc.)

[brainstorm]

What about the keybase client just signing the public SSH key with the user's GPG private key? That should be enough verification and it's simple enough since keybase already knows about GPG, isn't it?

[grawity]

Maybe. Despite the file name that OpenSSH uses, the keys aren't really identities, only login credentials, so they don't really need proof of ownership, just like the existing Bitcoin address field in keybase – if you add someone else's key, it's only a disadvantage to you.

[ghost]

So we want less confidence for login credentials than for my twitter username? :frowning:

[grawity]

Yes, because only you use your login details, while your Twitter profile is used by many people as a link to your identity.

If Keybase allowed you to claim any Twitter name, it'd mislead people into thinking you have access to that profile.

If Keybase allows you to post any SSH key, that doesn't happen: the opposite would happen. You'd be merely allowing a stranger to use your account, exactly as if you had added that stranger's keys directly into your own authorized_keys.

Saying that SSH keys are somehow more magic just because they are used for login is a pretty shallow argument.

And I was even one of the people who complained that Keybase did not verify Bitcoin address ownership... (Same situation though.)

[ghost]

Yes, because only you use your login details

I might have a friend who wants me to access their Mac so I can help them troubleshoot. I might have a coworker who wants me to have the ability to deploy to production systems. There are many use cases where someone other than me might want my login credentials.

And I was even one of the people who complained that Keybase did not verify Bitcoin address ownership...

We share that complaint. I was writing up my comment on 218 as you were replying here.

[grawity]

I might have a friend who wants me to access their Mac so I can help them troubleshoot. I might have a coworker who wants me to have the ability to deploy to production systems. There are many use cases where someone other than me might want my login credentials.

And the ownership proof still doesn't change anything, because it goes in the opposite direction than people would check. They already know your identity and your Keybase profile, and only you can add SSH keys to that profile. If you added a SSH key that you don't own the private half of, you'd gain nothing, only lose. An attacker, meanwhile, would most certainly have access to the private half of the fake key that they're trying to add.

[Kilobyte22]

The issue is that one can never fully trust a server. In theory keybase could manipulate the key. If it was signed and the signature was checked it would be easier

[grawity]

Hmm. That's certainly true; I should have remembered this.

And another reason is to prevent people from accidentally adding someone else's key they happened to have stored.

[ghost]

An attacker, meanwhile, would most certainly have access to the private half of the fake key that they're trying to add.

Hence, a proof. Which is signed using my PGP secret key. Now an attacker has to compromise my passphrase. Post the proof someplace external to keybase.io. Now an attacker has to compromise keybase.io and a 3rd party site.

[ghost]

The GitHub API List public keys for a user could be used in a proof.

The naive version would be to hash the response body of GET /users/:username/keys and include that in the "Signed Object" portion of the GitHub proof/gist. The advantage is the steps for independently verifying are more simply expressed, along the lines of:

curl -s https://api.github.com/users/toolbear/keys |shasum |awk '{ print $1 }'

Another advantage is that the API only returns verified keys (according to the docs, I've not tested this to confirm).

Disadvantages include:

• depends on whether the key IDs remain the same
• portions of the list are JSON objects which may have unstable key order
• breaks if you add/remove additional keys
• not clear which public key you intend to associate with keybase.io, or if you want to associate all of them

A variant on the proof would be to include the actual pubkey in the "Signed Object" portion of the gist, with verification being that that pubkey must be one of the keys listed via the API. The steps for independently verifying are more complex (well, the prose is less complex, but expressing it as shell commands using stock utilities is more complex).

[chesterbr]

+1 for the feature, regardless of whether it would be done via challenge signing or github.

[frdmn]

+1

[zzamboni]

I agree with @toolbear that since you are already verifying GitHub, an easy way to verify SSH keys would be to use the SSH keys that are stored in GitHub. Since you can have multiple keys registered with GitHub, Keybase could give you the option of choosing which keys you want to verify.

In any case, it would be a neat feature.

[jacoby]

Throwing my lot in with @toolbear and @zzamboni.

On Thu, Sep 25, 2014 at 10:52 AM, Diego Zamboni notifications@github.com wrote:

I agree with @toolbear https://github.com/toolbear that since you are already verifying GitHub, an easy way to verify SSH keys would be to use the SSH keys that are stored in GitHub. Since you can have multiple keys registered with GitHub, Keybase could give you the option of choosing which keys you want to verify.

In any case, it would be a neat feature.

— Reply to this email directly or view it on GitHub https://github.com/keybase/keybase-issues/issues/710#issuecomment-56830206 .

David Jacoby jacoby.david@gmail.com

[johnmmathews]

+2, my roommate says he is in as well ;-)

[tinloaf]

So what exacty does uploading a SSH key (any! SSH key) to my GitHub accout prove? Certainly not that the owner of the corresponding secret SSH key (who may be someone else) states 'I am that guy on keybase'. The whole GitHub-thing gives you nothing. The only thing you can achieve is a claim in the other direction: "The holder of this PGP key (i.e. this keybase user) claims to own this SSH key (which may or may not be true)".

These are the one-way proofs we already talked about, @toolbear . Uploading random stuff to GitHub does not benefit you in any way.

[malgorithms]

I agree with @tinloaf's concerns on this. An advantage of signing an SSH key and hosting in your sig chain on Keybase is a guarantee that you claimed that key publicly and timestamped (see our merkle/bitcoin docs for more info on this). For example, I could get your SSH key and know that you signed it and posted it months ago on Keybase, and you've never revoked/changed it despite making many more signatures since then.

With github, someone could've broken into your account today and changed your SSH key.

Or, scary and quite possible, someone could've broken into github today, and gotten their API to serve an extra SSH key for every single user. If people built access software off this lookup (a PAM module or something?), every server that used it would be exposed instantly to the hackers.

With a keybase signed key, you can go pretty deep in an analysis of when it was signed, whether it's been revoked, what other identities corroborate it, etc., with no server trust and no risk of MITM or forking.

The one question is whether/how to do two-way signing. Which github doesn't do either (you're taking their word on it, I believe. It's basically a 0-way proof).

If the only thing SSH keys will ever be used for is logging into a machine, then there is an argument that two-way proofs aren't needed. A 1-way proof is identical to having a signed conversation with that person you trust, where they ask you to add a certain key to your server's authorized_keys. Typically people don't actually prove they own keys when going through this process.

Still, 2 way proofs are preferred because it's fathomable you would want to do something with someone's SSH key beyond give them access to your machine.

[Kilobyte22]

We have to keep in mind that an ssh key is usually the only security barrier between the internet and an account on a server. Some people even allow root to log in using ssh keys effectively meaning that if you get that private key you essentially own the server. Therefore we gotta make extra sure that nobody can fake keys, even if your keybase account (or keybase in entirety) gets compromised. This eventually leads to the fact that the keybase client should verify the ssh key claim before it adds the key to your authoried_keys. Regarding the third party for the claim that @toolbear mentioned, i would suggest to use a gist (or maybe the ability to pick between different services). You would then sign your SSH public key using your PGP key. You might also want to have a claim other way round, but i think all you need here is a simple verification on keybases end, since this isn't really critical.

[johnmmathews]

Couldn't we take the benefit of timestamps into account as well? Verify the SSH key at that point in time as part of the check. If someone hacks Github and adds an SSH key for every user, that doesn't mean Keybase would validate that one as well until you do the full verification for the newly added SSH key as well. Just a thought to prevent editing/addition of keys, but this isn't perfect either. If you assume someone got full control of Github, they could potentially add SSH keys or edit the ones in place and then edit the timestamps to be what they were before. Bah.

On Mon, Oct 20, 2014 at 1:33 PM, Kilobyte notifications@github.com wrote:

We have to keep in mind that an ssh key is usually the only security barrier between the internet and an account on a server. Some people even allow root to log in using ssh keys effectively meaning that if you get that private key you essentially own the server. Therefore we gotta make extra sure that nobody can fake keys, even if your keybase account (or keybase in entirety) gets compromised. This eventually leads to the fact that the keybase client should verify the ssh key claim before it adds the key to your authoried_keys. Regarding the third party for the claim that @toolbear https://github.com/toolbear mentioned, i would suggest to use a gist (or maybe the ability to pick between different services). You would then sign your SSH public key using your PGP key. You might also want to have a claim other way round, but i think all you need here is a simple verification on keybases end, since this isn't really critical.

— Reply to this email directly or view it on GitHub https://github.com/keybase/keybase-issues/issues/710#issuecomment-59816986 .

Thanks, John Mathews

LinkedIn: http://www.linkedin.com/in/johnmmathews

[ghost]

Couldn't we take the benefit of timestamps into account as well - @johnmmathews

Shouldn't be necessary if we're PGP signing a claim for the SSH pubkey.

I would suggest to use a gist...You would then sign your SSH public key using your PGP key - @Kilobyte22

That's essentially what I proposed. Except I suggested the extra step of signing GitHub's API response, borrowing @brainstorm's idea of using GitHub as the best thing we have to an SSH pubkey 3rd party (which is debatable; I haven't entirely convinced myself).

This signed statement would be included in the Keybase GitHub proof (itself a gist). So, for example, my GitHub proof would become "I am @toolbear on GitHub. Also, this is my SSH public key".

Uploading random stuff to GitHub does not benefit you in any way. - @tinloaf

Agreed that I should have some skepticism of SSH key claims of strangers. But...

I might use this to retrieve my own pubkey, for example during automated provisioning of a server instance I manage. And since it's my own SSH key I can be confident I didn't upload "random stuff" to begin with; since I sign the claim I can be confident it hasn't been tampered with since then.

If I already know and trust someone that trust might extend to their SSH pubkey claim.

[ghost]

I admit the two-way proof by way of GitHub is a bit shoehorned; I find the complexity unsatisfying. But I'm a big fan of two-way proofs when possible (elaborated elsewhere), so I wanted to see if we could make something of it.

[malgorithms]

Couldn't we take the benefit of timestamps into account as well - @johnmmathews Shouldn't be necessary if we're PGP signing a claim for the SSH pubkey.

In defense of timestamps: if something was signed at a verifiable date in the past by a PGP key, and it hasn't been renounced/revoked, the further in the past the better.

If I steal your PGP key and sign an evil SSH key with it, and post the claim publicly, it's unlikely to survive 6 months without you noticing. Therefore, a provably older public signature is a better one. At least for this threat.

I wouldn't call this a crucial point or anything. Just that it's a bit of a plus. Before letting a colleague onto my server, I'd feel much better about an SSH key I knew was out there for them to review for an extended period of time.

Aside: @toolbear, to make the proof go both ways, how does a verifier get their hands on something that was signed with the SSH key? Are they just trusting Github's claim that it has seen a connection using that key?

[ghost]

Are they just trusting Github's claim that it has seen a connection using that key?

That was my original proposal, yeah. I haven't confirmed that GitHub's API behaves as documented, specifically that it only returns verified keys.

Complicating the proposal further, Keybase could sign a statement first with my SSH key and include that in my GitHub proof/gist (signed with my PGP key). Then a verifier can check:

• I have a proof hosted as a gist, signed with my Keybase PGP key, per the current GitHub two-way proof
• the GitHub proof contains a claim for an SSH pubkey
• the claimed key is one of the keys returned for my user from the GitHub API
• the GitHub proof contains a statement signed with my SSH key

I've since decided that PGP signing the response body from the GitHub API is almost certainly too brittle. The disadvantages are all the same ones I originally enumerated; my mind changed about them being acceptable. The alternative is that the verifier will check for the presence of the claimed SSH key in the GitHub API response instead.

[laurentstemmermd]

+1 for this killer feature

[tinloaf]

Keybase could sign a statement first with my SSH key and include that in my GitHub proof/gist

So, in how far does that proof anything that would not be proven by uploading the same thing to keybase.io (or pastebin, or any other site..)? Why push that proof out to some random, completely unrelated website?

[ghost]

I "second" what has been said before. Would be a lovely feature.

[ghost]

github-auth – a utility for easily setting up remote pairing via SSH and (presumably) tmux – treats GitHub as an authority on SSH public keys.

[ghost]

Why push that proof out to some random, completely unrelated website?

GitHub is more than a code/snippet hosting service. GitHub is also a social network for coders (so an authority on user identity) that happens to associate an SSH public key to a user (so the closest thing we have to a public authority on SSH public keys) that happens to expose a public API for getting the verified SSH public key for a user (so it can be used in a scheme that independently checks a claim or proof) that happens to be a service that keybase already cares about (so why not build on that to improve our confidence when someone claims an SSH public key?). Hopefully it's now clear why GitHub is neither random nor unrelated.

Any specific implementation suggestions I've made are likely flawed. But it still seems that we have all the pieces to do better than a one-way claim hosted only on keybase.io, even if we cannot achieve the big confidence boost of a two-way proof.

So, in how far does that [prove] anything that would not be proven by uploading the same thing to keybase.io (or pastebin, or any other site..)?

It might not prove anything additional, but why would I propose to post it elsewhere? My suggestion has been to incorporate GitHub's #list-public-keys-for-a-user API either by incorporating the API response directly into the claim (brittle) or indirectly by requiring that a claimed key must appear in the API response when independently verifying the claim.

To be clear, I suggest the claim be posted to keybase.io and GitHub for the same reason that I like that two-way proofs are posted on keybase.io and the relevant service.

[drewbug]

It's already common practice to add an SSH key to your GPG keyring as an subkey with only the authentication flag set, and to use gpg-agent in place of ssh-agent.

[cweagans]

...really? I've never heard of anyone doing that.

[grawity]

@cweagans Yes, not sure how "common" it is, but, it's certainly been done, especially with OpenPGP smartcards I think. http://blog.josefsson.org/2015/01/02/openpgp-smartcards-and-gnome/ and https://inuits.eu/blog/ssh-authentication-your-pgp-key, for example.

[cweagans]

Huh. Interesting. If I used PGP more, I might do that :P

[davidar]

:+1:

Also see http://web.monkeysphere.info/getting-started-ssh/

[zQueal]

SSH keys are in the end just asymmetric keypairs used for signing server's challenges. The client could sign a proof in the same way, perhaps even using ssh-agent.

You could use openssl dgst:

openssl dgst -sign ~/.ssh/id_rsa {proof_file}

Then to verify:

openssl dgst -verify {public_key} -signature {signature_file} {proof_file}

It's much more complicated than simple PGP proof verifications, and would require OpenSSL to be installed on the host machine (or if you do web-proof based verification; on the server), but it's entirely possible.

In practice:

# openssl dgst -sign ~/.ssh/id_sample $1 > $1.sig
# ssh-keygen -e -f ~/.ssh/id_sample.pub -m PKCS8 > pub
# openssl dgst -verify pub -signature $1.sig $1
Verified OK

More on this, here.

[leifj]

+1 for this feature. There is a lot of interest in compute-intensive research infrastructure for a way to tie external identities to ssh key(s) and keybase could be a way to do this.

[dijxtra]

Another +1 for this feature, or at least a blog post on how to do this properly. For now, here is how I solved this on a newbie level.

[exabrial]

+1 Agree... To "prove" they actually own the corresponding private key, either use a small script that uses OpenSSL to transform the SSH key into X509, then signs a message, or just have them login to an SSH server successfully.

[Efreak]

I'm all for this. I suppose that you could do this informally by placing your public key in your public/shared private folders, and simply using a script to copy/verify it, but automating it would be much nicer. I also recommend a proof of some kind over simply logging into a keybase ssh server.

regarding @malgorithms

how do we deal, for convenience, with either key portability or multiple SSH keys per user? I think many users have the workflow that they generate a new key pair with ssh-keygen every time they set up a new machine. If so, do they need to run a keybase command on each of these machines, and then, what gets added to authorized_keys? all of them?

I recommend naming individual keys. Something like keybase add-ssh-key ~/.ssh/id_rsa.pub desktop to add my desktop's public key to keybase. Possibly default to the public name of the local key, followed by a number. If I someone wants to allow me to log into their server, they can then run something like keybase get-ssh-key efreak would then ask them which key(s) they want to import to the local system, or keybase get-ssh-key efreak#desktop would only import my desktop key. If using the authorized_keys file it would also be nice to have support for extra options like from, environment, no-pty, etc.

[exabrial]

Still hoping to see this feature. Thanks!

[Cambridgeport90]

We definitely need this. Would make verification and setup much simpler.