FYI, this happens because SSH automatically presents a public key to the server when trying to authenticate. If the server doesn't know that key, then SSH tries the next one. You can enumerate all of someone's keys this way (like this SSH server does)
If you want to disable this sort of behaviour you can disable SSH from sending keys automatically, and then tell SSH which identity files need to be sent to each host.
In your .ssh/config, something like:
# Ignore SSH keys unless specified in Host subsection
IdentitiesOnly yes
# Send your public key to github only
Host github.com
IdentityFile ~/.ssh/id_rsa
This is also handy if you're security conscious and like to use a different private/public key pair for each host you have an account with!
Exactly! Once I get the keys I just check them against a scraped database of GitHub keys and ask the API for your name.
(And if you have agent forwarding active I show you a big WARNING [0].)
There's an explanation in the README [1] but the actually interesting stuff is in server.go [2]. Finally I mentioned a few reasons it might not work for you below [3].
> (And if you have agent forwarding active I show you a big WARNING [0].)
It amazes me that people enable that for random servers. Seems like SSH should make that harder. Enabling it for a specific server you trust makes sense; enabling it for all servers doesn't. SSH could reject "ForwardAgent" outside a Host block, for instance, and force you to at least write a "Host *" block.
For those who don't get why this is terrible, imagine if GitHub were compromised and their ssh agent tampered with. When you clone a repo, they could use your forwarded agent to log into your production hosts. That's pretty bad.
I don't fully understand how this would work - the key being "forwarded agent". My (poor) understanding is that in order for compromised github to get to a host I'm connected to they would somehow need to invoke ssh on my host, somehow. The only way that would not be the case is if ssh maintains an in-memory persistent thing that a) maintains connections to foreign hosts, and b) can somehow be signaled from active connections. If that's true, then a) I didn't realize it could do that, and b) it would be quite handy sometimes, although the security implications are rather serious.
The SSH agent maintains your private keys and provides the necessary responses to ssh when it wants to authenticate to a server. If you ssh to a server and forward your SSH agent, that server can then run ssh themselves and impersonate you to a different remote server, and your SSH agent will supply the necessary authentication information.
Or, in short: never use ForwardAgent (or ssh -A) to a server you don't trust.
The remote ssh process asks your host to unencrypt it's traffic? Your process takes an encrypted stream, sends the plaintext, and your keys never leave your machine. That's...incredibly clever, although I can only think of one scenario where it would be necessary (navigating securely through a sequence of ssh sessions where some of the secondary hosts are inaccessible from your originating host. E.g. a kind of "secure trojan horse".
Sometimes I feel just so awed at the ingenuity of people, especially with software and computers.
Not exactly. The remote host, which you have forwarded your agent to, tries to log onto your production host using your public key, and when the production host sends it a signing challenge to prove it has the authority of your private key, it can simply ask your ssh agent to do that signing. Once that is complete, you are logged in and the session has a session key that has nothing to do with your pub/private keys. The ssh agent does not do decryption, it just gets the session started.
Another example is if I want to transfer something from server A to server B, without it going through my shitty little pipe, and without storing the private key on either server.
I know it as a "jump host" or "jump box". Regardless, it's still not a good idea to have agent forwarding - what about the boxes you forward to? Do you trust them not to abuse the forwarding trust (Is there a way to limit forwarding trust to just one machine?)
Safer than dumping all your private keys onto the jump box and using that to validate the final target? Why yes. This way, your local ssh client validates the final target public key, not the jump box.
The whole point of agent forwarding is that you don't have to place your keys on the jump box. With -c for per use confirmation it seems much more secure.
There's something I found on hacker news awhile back that can allow you to use ForwardAgent while limiting your identities so that you can forward your ssh agent, but it only forwards the identity you used to connect to that server. It starts up a separate agent for each identity when you invoke it.
I also use the -c (confirm) flag with ssh-add. I don't forward the agent willy-nilly, but if someone still manages to compromise the agent, I will hopefully know when I'm getting confirmation popups I didn't initiate.
It's been awhile since I set it up, but I believe I've disabled gnome-keyring's agent[1], use the OpenSSH one instead, use ssh-askpass-keyring[2] as the SSH_ASKPASS environment variable to ssh-add to read key passphrases from the keyring (manually invoked via a shell script helper; but only needs to be done once per login session), and GNOME's gnome-ssh-askpass installed as the system default, for key confirmations.
(This is on the Cinnamon desktop, so other GNOME setups could be different.)
Holy mother of god, can we somehow return to the time when almost nobody used *nix and Microsoft was the one struggling to keep systems of these people secure?
I don't think this time ever existed, I remember some fifteen years ago using google to search for unshadowed /etc/passwd and vulnerable cgi scripts, and there were tons of results.
Thanks for the tip. I use ForwardAgent for all my servers at work, but I had it defined in a "Host *" block. I've now setup separate blocks for my work domains and have moved ForwardAgent into there alone. Never knew it was a risk until this thread.
Double-reading the man page I noticed that IdentitiesOnly makes ssh only send IdentityFile keys, however IdentityFile has a default of "~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 and ~/.ssh/id_rsa".
The result is that with this configuration you would still send id_rsa to unknown hosts.
You also need to add "PubkeyAuthentication no" to your global stanza, and re-enable it for good hosts.
# Ignore ssh-agent keys
IdentitiesOnly yes
# Disable public key authentication
PubkeyAuthentication no
# Send your public key to github only
Host github.com
PubkeyAuthentication yes
IdentityFile ~/.ssh/id_rsa
Ah, good catch! I don't normally name my keys after the default "id_rsa" so I didn't notice that. You will need that configuration you showed if you have keys that use the default value.
Is there a way to set that in bulk so all hosts in your config send identities, but those not specified don't, without putting IdentityFile for every one?
You can create a host block that matches multiple hosts:
IdentitiesOnly yes
Host first second third fourth
IdentitiesOnly no
If you then wanted to have per-host configs you'd have to create more host blocks, but at least this way the added overhead of "IdentitesOnly yes" doesn't grow too fast with the number of hosts involved.
I added IdentitiesOnly to my config recently. Partially for security. But also because an non-Github git service would bail whenever too many incorrect identity files were attempted. I've also had SSH servers bail when trying too many keys/identities.
Yeah, IIRC the error with too many identities is hard to diagnose (something generic like "too many authentication failures"), until you add -v and see all your keys being presented.
Yes, provided that the server accepted the second key the rest would not be sent. However, the server can simply respond that each key is incorrect (regardless of if it is or not), and then get all five keys.
Once SSH has ran out of keys to try, it tries to move on to other authentication methods. The go app he has written then automatically accepts the connection at that point, once it knows it has seen all of your keys.
It allows you to do things like have varying passphrase strength on your encrypted keys, depending on how much you care about keeping each one safe; or putting only the private keys you usually need on each device, rather than one/few keys that will get all your systems pwned if it's compromised.
Exactly. Additionally, if I associate a new key pair with each host then I know I can discard + regenerate that key and it only affects that host. Each machine can have their own pairs as well.
If a key is compromised, it only provides access to a single host, not _all_ of them. This allows much more fine-tuned key management and reduces the scope of a key compromise.
Plus, it's not really that much more work. Just name your key after the host it's for, and then add an IdentityFile directive in your SSH config. I never have to worry about it, and get all the benefits.
+---------------------------------------------------------------------+
| |
| _o/ Hello! |
| |
| |
| Did you know that ssh sends all your public keys to any server |
| it tries to authenticate to? You can see yours echoed below. |
| |
| We tried to use that to find your GitHub username, but we |
| couldn't :( maybe you don't even have GitHub ssh keys, do you? |
| |
| By the way, did you know that GitHub publishes all users' |
| ssh public keys and Ben (benjojo.co.uk) grabbed them all? |
| |
| That's pretty handy at times :) But not this time :( |
| |
| |
| P.S. This whole thingy is Open Source! (And written in Go!) |
| https://github.com/FiloSottile/whosthere |
| |
| -- @FiloSottile (https://twitter.com/FiloSottile) |
| |
+---------------------------------------------------------------------+
* Your ssh version uses only recent algorithms not supported by Go's x/crypto/ssh
* You actually disabled IdentityKeys
Nothing to do with usernames or heuristics, by the way. All it does is first enumerate your client keys, then let you in, then check a huge GitHub keys database, then ask the GitHub API for your name.
It also does not work with keys from a smartcard (yubikey NEO). Here is the ssh log:
debug1: Next authentication method: publickey
debug1: Offering RSA public key: cardno:000603010929
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Trying private key: /home/pbonzini/.ssh/id_rsa
debug1: Trying private key: /home/pbonzini/.ssh/id_dsa
debug1: Trying private key: /home/pbonzini/.ssh/id_ecdsa
debug1: Trying private key: /home/pbonzini/.ssh/id_ed25519
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Whenever I push, I login. Apparently this laziness saved my ass this time. Of course, this could be used on any service I ssh into regularly and has a scrappable listing of users, so it's good of you to bring this up.
That's a very good thing to keep in mind when reading any complaints on the Internet and using them to gauge sentiment about a thing. Folks who are happy with a thing are far less likely to take the time to write up their experience than those who are unhappy.
It's probably most apt to working when the local username is the same as the username in your SSH keys.
If your local username is something like "johndoe", while your server logins (and keys mapping to them) is "jdoe", it isn't likely to align the one to the other.
If your local and remote usernames tend to be the same, and they are also the same as your Github keys, then it's probably pretty likely to be accurate.
Didn't work for me, not because I don't have a Github key, but because I use separate keys for everything, and don't have a default key (requires plenty of ~/.ssh/config muckery).
I had been doing this because I'm paranoid, and because I have a tendency to copy keys for my colo boxes to work computers, and my Git keys to the colo boxes. Now I have a new reason -- public keys basically act like a giant supercookie for SSH.
Same here. Here's my ~/.ssh/config for anyone interested in what it looks like:
Host github.com
User toxicFork
IdentityFile ~/.ssh/github-toxicFork
Host bitbucket.org
User toxicFork
IdentityFile ~/.ssh/bitbucket-toxicFork
And my personal security policy:
- Once I want to use a device for development, I create separate key pairs for all of the services I want to use, register it on that server's account config and then add it to my config file by hand ( I should find or write a script to do these automatically :D )
- Once I want to retire a device (or if it gets lost) I just remove the public keys from the services
- NEVER move or copy private keys, I'd rather create a new private key and remove the references for the old public keys instead
Good policies, the mere presence of an id_<ciphername> key in .ssh means you can be identified between multiple ssh servers. I identified this in the OpenSSH source a while ago and posted it on reddit at one point, but few people understood. Glad someone made a practical attack out of it now. IP correlation may seem a more obvious attack, but such an attack could be used to identify for example, someone running a darknet operation or using VPNs for privacy or simply to tie an IP to a name using a public key service like in this example.
Also - everybody should probably be aware that SSH zero-day isn't the only bad thing which can happen to you if you connect to a malicious SSH server. Your terminal emulator has a higher chance of being vulnerable (e.g. take a look here: https://www.proteansec.com/linux/blast-past-executing-code-t...) than openssh does.
P.s. "(And written in Go!)" - the trick would still be very cool if it was written in C, JavaScript, PHP, COBOL or any other language (and it would be freaking awesome if written in brainfuck!).
There's also another leak which isn't really shown here and that leak is that, with just a public key, you can offer to servers and they'll tell you if it's present or not.
Using this you could scan the internet (given 6-12 hours and a shitty VPS that you can throw away this is quite possible) for someone's public key to find all of their servers, which could lead to a bypass of DDoS protection, identification of a Tor hidden service, etc.
It occurs to me that you could use this same mechanism to reduce the configuration load on machines that provision users using cloud-init(8).
Right now, cloud-init accepts a list of GitHub usernames that should be allowed to log into the machine (which is pretty clever in-and-of-itself), and then creates users for them and sets their authorized_keys to whatever values the GitHub public-SSH-key API returns.
But, rather than "burning in" a set of allowed users, you could do something much more interesting: allow any key to authenticate, and then map it back to a user and find out if that user has write-access to the GitHub project!
It will probably work. But it seems like you are increasing the attack surface here: the current method gets the list of keys once, and if github isn't compromised at that very instant in time, you are safe. Your proposed method relies on trust in github at all times.
Wow after both of those blog posts, TWO years ago, I'm surprised github hasn't stopped exposing this identity information and us HN users haven't started being more paranoid about our ssh_configs.
Public keys are meant to be public, so is it a problem if everyone knows your public key? How often do you want to SSH into a remote server while wanting to remain private? And supposing you really want to, can't you maintain separate keys for separate hosts as other commenters have suggested?
why would they? after all they are public keys, they are supposed to be public. if you really are afraid of github exposing your public key, I think you can always create a separate pair to use only with github.
And in some sense github is doing as a favour, by partially solving the key distribution problem.
If you send me your public key via email, I don't know whether you are who you claim you are. If I get your public key via github, at least I know that you are the person contributing to all those open source projects.
I see most people acting like this was obvious but I gotta believe that a clear majority of ssh users had no idea about this. Yet it's extremely obvious when you think about it.
This, this is true hacking. This is so elegant. I love you Filippo. Keep being awesome!
> By the way, did you know that GitHub publishes all users' ssh public keys and Ben (benjojo.co.uk) grabbed them all?
> That's pretty handy at times :) But not this time :(
>Better luck next time, I guess :)
Who cares if they publish Public Keys. They're meant to be public, it's one of the few well named things in computer science. They are basically meant to be spewn everywhere.
DOS is a bit of a misleading term here. You're not actually denying them service at all. You're just tricking the service provider into potentially mis-identifying them as a different user, depending on how their SSH is configured, and it's easily solved by a small SSH config change on their end. And it only works against someone who has multiple keys anyway.
> A simple solution would be to avoid the single user login git@service.com, and use that as identification, for example gmalette@service.com.
Except this completely ignores the reason why services use git@service.com. It's not because they're lazy. It's because the URL is supposed to identify the project, not the user. If the URL included the user's own username, that URL wouldn't work for anyone else, which breaks git-submodules, breaks any kind of config file that specifies repositories (e.g. for use by a CI server), and removes the ability for people to copy&paste a `git clone` command from a README (or blog post or wherever else).
So yes, there is a theoretical annoyance attack here, but nobody really cares because it's never going to happen accidentally, it can't be used against most people, and it's so trivially bypassed nobody's going to bother doing it except as a PoC. The benefits of using git@service.com greatly outweigh the downsides.
> and it's easily solved by a small SSH config change on their end
The article does mention it. The issue is not fixing the problem, it's actually finding it.
> [...] that URL wouldn't work for anyone else, which breaks git-submodules, breaks any kind of config file that specifies repositories (e.g. for use by a CI server)
It doesn't explain why Heroku uses it. Do you really push different submodules to Heroku?
For Github et. al, that's easily solved by project-level or organization-level identity.
> that URL wouldn't work for anyone else
And using `git@` doesn't work if you use multiple accounts because you'd specify the IdentityFile by host.
> nobody really cares because it's never going to happen accidentally
Except it does. Those service providers often get contacted because this happens BY ACCIDENT.
I've done it to myself by adding my public key to my work account. I couldn't access my personal stuff without changing my SSH config.
A while ago at work, we were using a shared key that was used to setup the initial vagrant config. New hires often added that key to their github or heroku account.
> It doesn't explain why Heroku uses it. Do you really push different submodules to Heroku?
I don't use Heroku, but, sure, why not? If I push a repo to Heroku that includes submodules, presumably Heroku then fetches those submodules (I'm assuming it supports submodules at all, which seems like an obvious thing to support). Therefore, those submodules must be specified by a URL that works for everyone, not just you.
> For Github et. al, that's easily solved by project-level or organization-level identity.
How does that solve anything? You're no longer identifying the user whose key is supposed to be used, which means this no longer solves your problem. And if you're going to suggest that it should only consult users who have access to the repo, for a public project that's everybody, which makes it functionally identical to git@.
> And using `git@` doesn't work if you use multiple accounts because you'd specify the IdentityFile by host.
Sure it does. IdentityFile is explicitly allowed to be specified multiple times for a single host, and the files will be tried in turn. So you can specify all your keys that way.
> Those service providers often get contacted because this happens BY ACCIDENT.
Someone uploads a private key that doesn't belong to them by accident, that screws up other innocent people? I'm rather skeptical. What's your source on this? And no, your own anecdotes do not constitute proof that providers often have to deal with this.
> A while ago at work, we were using a shared key that was used to setup the initial vagrant config. New hires often added that key to their github or heroku account.
Your work is handing out a shared public/private keypair and encouraging people to set this up as a default identity in SSH? That sounds awful, and it's entirely a problem you created and not even remotely the burden of GitHub or Heroku to care about.
> If I push a repo to Heroku that includes submodules, presumably Heroku then fetches those submodules
You're missing the point. You may use submodules hosted on github with Heroku, but you don't use Heroku to host that repo. You're not going to `git submodule add git@heroku.com:project`. So for the sake of argument, if we pretend that git repo hosts do need to use `git@`, I don't see a single reason why Heroku would.
> And if you're going to suggest that it should only consult users who have access to the repo, for a public project that's everybody, which makes it functionally identical to git@
Now you're confusing two things. Do you want to clone a public module as a subrepo, or allow commit access? Public repos can be cloned without identification. If you want commit access, why would project-level not work?
> Sure it does. IdentityFile is explicitly allowed to be specified multiple times for a single host, and the files will be tried in turn
Again, missing the point. If you don't specify a different host, you'll always be identified and authenticated as the first key that matches, therefore you'll only use a single account. That's why you have to use different hosts.
> And no, your own anecdotes do not constitute proof that providers often have to deal with this.
If you're not going to believe anything I say, I got nothing. Otherwise, 2 things
- I opened an issue and the response was basically "Ooooo that explains some of those tickets". They specifically mentioned issues with vagrant.
- I presented this at a local meetup and someone else had put themselves in this position.
> Your work is handing out a shared public/private keypair and encouraging people to set this up as a default identity in SSH?
No. As I said, it was meant to setup the vagrant box and then not be used. By default vagrant connects using an insecure keypair.
> You may use submodules hosted on github with Heroku, but you don't use Heroku to host that repo.
Ah, I see what you mean. But is that actually true? If you push a repo to Heroku, are you still expecting to host the canonical version of that repo elsewhere, instead of just using Heroku as the canonical version? Because if it's the latter, and you're working with other people, then it's still useful to have a single URL that identifies the repo.
> Do you want to clone a public module as a subrepo, or allow commit access? Public repos can be cloned without identification.
But you're going over SSH, so you have to negotiate the connection before the server knows what action you're taking. So the SSH connection will be the same whether you're pushing or pulling. You can't negotiate different identities for pushing vs pulling, so whatever identity you settle on has to work for both.
> If you don't specify a different host, you'll always be identified and authenticated as the first key that matches, therefore you'll only use a single account. That's why you have to use different hosts.
Ah, I see.
It sounds to me like using username@ is still completely useless regarding your proposed "attack", but does have some small utility for people who have multiple accounts. But I still think the obvious general utility of having a single URL that works for everyone is more important.
As an aside, it looks to me like you could try using the `Match` keyword in your ssh_config and have it run an external command that determines which account you should be using. This could be controlled with an environment var, or maybe it could look at $PWD. If you can come up with some suitable command, then you can use that to control which identity file to use.
> If you're not going to believe anything I say, I got nothing.
I believe your personal, anecdotes, but you can't just make a broad claim about providers with no evidence and expect me to believe that it really is as widespread an issue as you claim.
"It's because the URL is supposed to identify the project, not the user. If the URL included the user's own username, that URL wouldn't work for anyone else."
Couldn't the URL just not include a username, though? Then when git tries to establish an ssh connection, it could try the local username (like ssh does by default), or a username specified somewhere in a config file.
You can dos someone just by knowing their ip or how to get a hold of them. You can also sign up magazines to be delivered to their office address and DOS their workplace.
There may be some people concerned with GitHub publishing their identity to everyone, but it is pretty easy to use a separate key for GitHub (they'll even generate it for you) if you configure your ssh client appropriately with Host sections. Also, the same technique works if you want to use two different accounts on GitHub (one for work & one for personal). http://stackoverflow.com/questions/19310368/using-two-ssh-ke...
Forgive me ignorance here but what steps should I take to avoid someone from getting my public key off github and then using it to screw with my repos? Was there a major step I missed here when I made these keys?
It's public key because it's named such in the context of public key cryptography. But not all public keys should be available to public.
Ideally by default ssh client should use a different key pair for each server('s public key) it connects to. Some people want to hide their identity, for example Tox people chose to be anonymous, what SSH does goes against expectations so it has the ability to betray their choice.
If you trust your connection to Github and trust that the person in control of the account is the person the account represents, then why not trust that key?
To make it easier. Your public key is something others would place on their servers to grant you access, and you'll need to have your private key to authenticate.
Don't use agent forwarding to any host you don't have exclusive root access to and are 100% sure isn't compromised. Anyone else who is root on a box you SSH to with agent forwarding can authenticate to other servers using your private key while you are connected.
The host you're connecting to could be able to, force write/destroy your public repos or clone your (and your employer's) private repos given that he knows their paths, eg: github/github. I'd assume that a few companies have a */secrets repo of some sort.
Ooh goodie, we get to re-open the argument about whether it was bad of GitHub to publish the public keys![1] Pick your talking points: "They're called public for a reason.", "This could enable identity tracking.", "If your security model prefers public keys to be kept secret, it's absurd -- security by obscurity.", "This could enable factoring weak keys.", "This is good for security research.", "It's wrong to reveal metadata without consent, even if it doesn't break the crypto."
You could build in another PoC by doing the trick where you hide a command inside the copy-paste version of the ssh command line you gave.[2]
A great reminder that public key identity management is quite the unsolved annoyance. Why should you use the same key everywhere, allowing others to track you? Ideally you would have one key per service.
Pretty interesting. Although it couldn't find my github ssh keys for some reason. Maybe the database has some stale entries? I imagine it's quite a lot of user data to go through and process.
That's actually super handy. Next time I have to add someone to a shell account, I'll probably just look them up on GitHub first to find their public key instead of asking.
... thereby making any successful manipulation of the github key database (by the github people or by an attacker, as has happened before - google e.g. http://egorhomakov.com/ ) a successful penetration of YOUR system.
Security and convenience unfortunately conflict often.
A good reminder that your public keys are, in fact, public. For most people, this is probably a good thing, unless you're specifically trying to hide your identity.
I use different keypairs for different trust domains. (also makes it easier to hand over access when you quit a job.)
SSH keys are actually pretty horrible from a security perspective; no expiration, generally held in software, etc. And without a lot of work, single-factor. I love the ssh security model of being pretty good and better than telnet for everything (which it ~fully displaced, unlike https vs. http), but client keys are one of the weak points.
By the way, we use a security fob at work for that. Seems to work fairly well. The private key never leaves the fob, you have to press a button to sign anything, and every once in a while you have to enter your passphrase.
passphrase is set/unset locally and not communicated to the server if it is present/used/etc. Could be disabled. along with various other things.
HW token with ssh key inside is probably the best. The annoying thing is devices w/o USB. For iOS devices and android devices which support it it's probably better to just use the HW sec features. Something which did bt 4.0le and maybe had a single local LED and button would be better still.
The newer small ones work really well. You just leave them permanently in a USB port. Every once in a while you have to enter your passphrase to keep them activated (eg reboot), normally you only need to touch them to sign / log-in. The requirement for touching comes from the fob itself, and can't be overridden by our computer.
For most operations you only need your gnubby. For some more sensitive ones, we require password + gnubby touch. (You are allowed to reuse your password as the gnubby activation password.)
At first I thought that leaving the gnubby permanently in the PC would weaken security, but essentially it just means that your PC (including gnubby) is your second factor.
You can have more than one gnubby. We recommend one per computer you are using. We allow falling back to the Google Authenticator app on your phone. (It's less convenient, and potentially phishable, but otherwise secure enough.)
The earlier fobs were technically usb keyboards and were just outputting a six digit string when touched (equivalent in security to the app). The new fobs do a little cryptographic dance with the website, and are thus more secure.
From my user's point of view, it's working very well. It saves me typing my password every two minutes. And the security guys assure me it's more secure, too.
Neat stuff. You could use this to let users identify themselves to services/ssh services via pubkey as their GitHub username - like https://github.com/shazow/ssh-chat - but with users automatically unique and identified by GitHub.
So I SSHed in. I got the message. Then I saw all the people freaking out here and couldn't believe my eyes.
Ask yourself this:
How often do you SSH in to arbitrary hosts? Ones that you don't control, or work for, or trust with your source code?
Did you really expect that you could give the same long unique base64 string to a bunch of different hosts and NOT have them connect your identity between them?
Do you not understand that the whole point of public keys is to uniquely and reliably identify yourself to an arbitrarily large number of parties?
Honestly, the only real eye-opener here is that Github gives out your public keys and can be scraped to collect all of them. But some of us have been using that functionality to share / snag each other's public keys for a long time now anyway.
As much as the keys contain public data, I wouldn't consider (but it apparently is) the list of keys with access to my github account public data. Github willingly reveals information about pseudonyms, etc.
This is a data vs metadata thing, the data is public, but who it belongs to, and what one can do with it need not be.
Though it may be incredibly impractical or theoretically impossible, depending on the key and time of day, there is always a possibility that a public key can be used as an attack vector to guess a private key.
You should be using different key pairs on each client machine you log into. You should also be using different key pairs for each host to which you connect (and using ~/.ssh/config to specify which keys are sent to which hosts.)
Not only will this limit correlation as demonstrated here, but also make it much easier to revoke access via keys that may have been compromised.
Does the server get the client's public key before or after the client has identified the server? I suspect it's after - which would imply that this is much less harmful than it looks like, since by then you've already confirmed the identity of the server.
So if my assumption is correct (some quick googling for images of the ssh key exchange suggests it is), then the reason it "works" in this case is because people intentionally say "yes" when presented with the fingerprint, just to see what would happen. If you were ssh-ing to a server that you've used before, there is little to worry about because the ssh client first authenticates the server, and the server presumably needs to know who you are anyway.
It should be safe to say "yes" to any fingerprint from any server you don't trust (as long as you don't send any sensitive information over the connection, or trust information coming from it). The risk is that you accept a fingerprint for a server you do trust, allowing some other server to steal that trust.
"publickey: The details of this method depend on the public-key algorithm chosen. In essence, the client sends a message to the server that contains the client's public key, with the message signed by the client's private key. When the server receives this message, it checks to see whether the supplied key is acceptable for authentication and, if so, it checks to see whether the signature is correct."
Didn't work for me because I use a separate key for each "class" of machines, where class is github, bitbucket, work, home, ...
You can reduce the maintenance load by using the %h (remote hostname) and %r (remote username) substitutions in IdentityFile. I make a symlink from the key I want to
e.g. id-rsa-<remoteuser>@<remotehostname>.key and use IdentitiesOnly.
See 'man ssh_config'
Use %u (local user) and %l (local hostname) for extra control.
It doesn't have %p (port) but the Host parameter in future versions of openssh will let you match on that too.
Luckily, putty/kitty does not send anything to unknown hosts. Good try though. Please accept a record of my IP address connecting to your honeypot as a token of gratitude.
weird idea: server that hosts open source git repos, but won't let you ssh in to clone unless your GitHub account has contributed to an open source project this year.
I wish there was a way to have ssh automatically ssh-add keys you use... with a expiration date. I've tried to get this to work a few times, but I use a unique key for every login, so I need something to parse ~/.ssh/config to find the right Host def and ssh-add it. The code is obviously in ssh, but it's not exposed to the command line as far as I can tell.
Let's say I downloaded every public key from GitHub to ~/.ssh. Would this identify me as everyone on GitHub, or just the owner of the first public key to match?
Furthermore, I wonder how Go channels compare to libevent (more specifically, epoll/queue) for high-performance network software. Is there any previous work which compares the two?
> FYI, this happens because SSH automatically presents a public key to the server when trying to authenticate. If the server doesn't know that key, then SSH tries the next one. You can enumerate all of someone's keys this way (like this SSH server does)
Therefore, even though I can't authenticate as Linus Torvalds, an SSH server can see me present his public key and hence, log that public key for future use, like sending a message? Is that not correct?
I dont want to "play" with ssh_config file. My concern here is how pageant/ssh-agent behave, i think i'll try to fix/find a way around that (e.g. attended calls to agent signing api / configurable calls to agent keys listing).
I think i'll drive a node-webkit/systray project being an alternative to pageant (#nwagent on freenode)
Not necessarily. The "public" in "public key" is not an announcement of intended global availability, but rather role in contrast to "private key". There are many reasons people or systems might want to keep "public keys" obscured or pseudonymous.
Still, many probably don't mind the public disclosure of Github account public keys.
But, the more serious issue here goes beyond that. In an unexpected and likely unintended way, one's Github identity is revealed to a third party, along with your origin IP and quite possibly other SSH keys used with other systems.
It's that set of mappings – IP <-> Github identity <-> other identities – that violates expectations.
Using the same public key on two sites is like using the same username - something that you would do only if you want your identity linked between those sites. It's also a much stronger proof of identity than having the same username, because that's what they were designed for.
like google analytics cookies track your every activity on every website, sending public keys feel the same way.
now I have to re-evaluate my ssh usage after discovering ssh sends all my public keys. need to setup per server identities, without too much usage hassle .
No sure if I am missing something here, but that's the idea behind PKI infrastructure: You can share your public keys without putting your identity at risk.
The "server knows who you are" or rather, I "tell the server who I am"
I first thought this was something new but wait he just gets public ssh keys. It is public for a reason, meaning anyone can have it and they are frankly useless. Can't find any comment below saying why this is dangerous ?
+---------------------------------------------------------------------+
| |
| _o/ Hello! |
| |
| |
| Did you know that ssh sends all your public keys to any server |
| it tries to authenticate to? You can see yours echoed below. |
| |
| We tried to use that to find your GitHub username, but we |
| couldn't :( maybe you don't even have GitHub ssh keys, do you? |
| |
| By the way, did you know that GitHub publishes all users' |
| ssh public keys and Ben (benjojo.co.uk) grabbed them all? |
| |
| That's pretty handy at times :) But not this time :( |
| |
| |
| P.S. This whole thingy is Open Source! (And written in Go!) |
| https://github.com/FiloSottile/whosthere |
| |
| -- @FiloSottile (https://twitter.com/FiloSottile) |
| |
+---------------------------------------------------------------------+
And for those that want to see what a successful key check looks like:
+---------------------------------------------------------------------+
| |
| _o/ Hello Evan Tschuy!
| |
| |
| Did you know that ssh sends all your public keys to any server |
| it tries to authenticate to? |
| |
| That's how we know you are @tschuy on GitHub!
| |
| Ah, maybe what you did't know is that GitHub publishes all users' |
| ssh public keys and Ben (benjojo.co.uk) grabbed them all. |
| |
| That's pretty handy at times :) for example your key is at |
| https://github.com/tschuy.keys
| |
| |
| P.S. This whole thingy is Open Source! (And written in Go!) |
| https://github.com/FiloSottile/whosthere |
| |
| -- @FiloSottile (https://twitter.com/FiloSottile) |
| |
+---------------------------------------------------------------------+
After the question of adding this server to known hosts OS X asked me for the passoword of my private key. Is this normal? Of course I refused and got the message like displayed in other comments.
In all seriousity, I would love a similar SSH server that automatically uses keys from GitHub for authentication. Great for setting up a little private git server without fiddling with keys.
It didn't work for me even though I have a github account and ssh key installed from the same machine. Maybe related to the fact I use several keys and keychain to manage keys.
I’d noticed before that ssh was rather aggressive about offering public keys to servers, but I didn't know Github published my public keys, and so this totally surprised me.
Go has a great SSH library from what I can tell. I'm currently working on a project that is based around SSH, and Go seemed to be the only real option.
At first, I thought that this is pretty harmless, but now I suspect that there may be a way to exploit a dump of public keys tied to personal information: let's say that some powerful adversary (like NSA) uses some kind of rainbow tables to associate public keys with private. Having a lot of public keys, they are likely to know some private ones and identities behind them.
This hypothesis requires some mathematical ground, though. It may be that probability of guessing a private key is still negligible.
The only thing that comes close to it that I can think of is the problem where weak public parameters were hard coded in a library (Apache) and were used by many many many person. Look at the logjam paper.
Not exactly a cryptography guy, but I don't think PKC quite works like that.
Rainbow tables rely on people using the same password as each other. This happens a lot with passwords, but it's unlikely to happen with key pairs, assuming they're generated with proper CSPRNGs.
It prints a message and immediately boots you out. By default, Putty will close the window when the connection terminates. Here is the message I got:
$ ssh whoami.filippo.io
The authenticity of host 'whoami.filippo.io (178.32.139.168)' can't be established.
RSA key fingerprint is c8:9a:b0:9d:59:96:24:37:70:4c:ef:eb:31:47:68:40.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'whoami.filippo.io,178.32.139.168' (RSA) to the list of known hosts.
+---------------------------------------------------------------------+
| |
| _o/ Hello Jason Hutchinson!
| |
| |
| Did you know that ssh sends all your public keys to any server |
| it tries to authenticate to? |
| |
| That's how we know you are @zikes on GitHub!
| |
| Ah, maybe what you did't know is that GitHub publishes all users' |
| ssh public keys and Ben (benjojo.co.uk) grabbed them all. |
| |
| That's pretty handy at times :) for example your key is at |
| https://github.com/zikes.keys
| |
| |
| P.S. This whole thingy is Open Source! (And written in Go!) |
| https://github.com/FiloSottile/whosthere |
| |
| -- @FiloSottile (https://twitter.com/FiloSottile) |
| |
+---------------------------------------------------------------------+
Connection to whoami.filippo.io closed.
Strictly speaking, it didn't fail; PuTTY on Windows works a bit differently from command-line ssh on OS X/Linux, and doesn't show you everything. It brings you directly to a "login as:" prompt after throwing up a dialog about missing/unknown keys. What you were supposed to see never made it to the screen.
Interesting. When I tried it at work earlier (Windows 7, latest PuTTY) it closed out the window without showing anything. I just tried it at home (Windows 10, latest PuTTY) and it worked as you said.
Right there in front of me. Now I'm wondering when and why I changed that behavior at home (I'm assuming the "Only on clean exit" setting is the default).
If you want to disable this sort of behaviour you can disable SSH from sending keys automatically, and then tell SSH which identity files need to be sent to each host.
In your .ssh/config, something like:
This is also handy if you're security conscious and like to use a different private/public key pair for each host you have an account with!