Writing

Software, technology, sysadmin war stories, and more. Feed
Saturday, July 20, 2013

Seeking permissions with SSH public keys with help from GitHub

Remember back in April when I wrote about how GitHub exposes your ssh public keys to the world? Back then, I had a half-baked idea about using it to establish identities of people trying to connect.

I've since discovered another use. Apparently, you can take a public key and use it to generate a ssh login attempt without actually doing the sort of crypto stuff which requires a private key.

Seriously. Check this out.

If you want to try to replicate this yourself, here's what you do. First, create a test account, then in that account create a .ssh directory mode 0700 and an authorized_keys file in that, mode 0600. Then, in another account, use ssh-keygen to make a public/private key pair. Take the public key only and copy it into some other filename that has no relation to the private key, or delete the private key. It doesn't matter.

Now try to connect as the test user in verbose mode using that public key. It'll look like this: "ssh -v -i public.key.file user@host". It'll spit out a lot of garbage and then it will either ask you for a password (if the host allows password auth), or it'll bomb. The point is, nothing useful will happen.

Now take the public key contents and paste it into the authorized_keys file in the test account. Then run the same ssh command again. You should get a very different result.

This time, you should see something like this:

debug1: Server accepts key: [...]

Then it'll probably complain about an unprotected private key file and will fail, but that's not important. The point has been made: this public key is known to exist in that account's authorized_keys file. This by itself is not enough to let you break into an account, but if you're doing some kind of security analysis, being able to figure out who can get to what is a great place to start. If there's an organization with 50 role accounts and 500 employees, being able to narrow down the possibilities for the most tasty accounts can save you a lot of work. Once the targets are known, you can specifically pursue them and try to compromise their private keys.

So here's the new evil idea: scrape GitHub, get all the public keys you can, then try all of them against every ssh account you can find. Then build up a list of which mappings look particularly interesting and start chasing them down.

I think I have a good bit of key auditing to do now. I now consider anything I might have stored out there in the past to be less than ideal for continued production use.

You might consider doing the same if this bothers you at all.