51–60 of 90 posts
Since Github SSH keys are public for every account, wouldn't anyone be able to impersonate you if they know your username, if you haven't set up a passphrase? If yes, it is surprising to me that Github does not make it abundantly clear when you add a key. Until now, I thought the only way an attacker can get my keys is if they break into my computer. Edit: totally disregard this, absolute brain fog moment
Since Github SSH keys are public for every account, wouldn't anyone be able to impersonate you if they know your username, if you haven't set up a passphrase? If yes, it is surprising to me that Github does not make it abundantly clear when you add a key. Until now, I thought the only way an attacker can get my keys is if they break into my computer. Edit: totally disregard this, absolute brain fog moment
How can someone impersonate you?
Today I learned that GitHub keeps a publicly accessible list of all pubkeys linked to each user's account.
It can be served up over HTTP too, given the username: https://github.com/${username}.keys Age (the author's file encryption tool) can make use of this when encrypting a file to send to someone.
You can turn this behavior off in .ssh/config with Host * PubkeyAuthentication no Put that at the bottom of the file, then turn back on for each host: Host site.com PubkeyAuthentication yes
This seems like bad advice, password auth is less secure than key auth^. And many servers don't accept password-based auth at all. ^password is sent to the server directly; passwords are generally weak and easy to brute force. Pubkeys without a passphrase _can_ be stolen from the local machine, but if an attacker has access to your local machine, you are probably SOL anyway. edit: as several people have pointed out,…
Today I learned that GitHub keeps a publicly accessible list of all pubkeys linked to each user's account.
I have always had ssh-keygen write out the keys to a custom path like ~/.ssh/keys/$service/$key{,.pub} and configured each host's "identity" manually with the ssh config file.
I never did this for security purposes or anything, I just thought it made more sense than the default behavior.
Since Github SSH keys are public for every account, wouldn't anyone be able to impersonate you if they know your username, if you haven't set up a passphrase? If yes, it is surprising to me that Github does not make it abundantly clear when you add a key. Until now, I thought the only way an attacker can get my keys is if they break into my computer. Edit: totally disregard this, absolute brain fog moment
When you call GitHub, after the server proves who it is to the client we get to user authentication, the client says e.g. "I'm tialaramex, and I can prove it, I know tialaramex's private key corresponding to public key 123456, and also private key corresponding to public key 987654". The server looks at the claimed user identity and keys and it can decide it wants to see that proof, for a real SSH server that'll be because it knows those keys are allowed to authenticate for that user (e.g. on a default Linux they're in the user's .ssh/authorized_keys file)
But whoami isn't a real SSH server, it's just looking at the claims, and anybody can make such claims.
If you get my GitHub public key, and you tell whoami "Yeah, I can prove I'm tialaramex, I know the corresponding private key for this public key" the whoami service doesn't actually check you can do that, it just says OK, I guess you're tialaramex.
A more nefarious thing is possible, which I'll mention but it isn't what whoami does. If you run a broadly used SSH server which actually authenticates users, you could scan those public keys against data sets like the one from GitHub, and correlate your users. So e.g. you can see that "Kittens4Ever" on your service is using the same key for that service as "DogsRuleCatsDrool" on GitHub and now you know those are in some sense the "same person". This can't be spoofed because you're actually checking those private key signature proofs, which whoami does not do.
This key correlation is why Security Keys (say a modern Yubikey, or cheaper alternative tokens) mint a brand new random private key for every enrolment. When I enrol the exact same token at Live.com, at GitHub, and at Facebook, the device mints three separate keys which can't be externally correlated, even though I can sign in seamlessly in all three places. So I could authenticate to the Live.com account "HackerNewsNoob" and the GitHub user "DanGFanClub" which says I've followed the site for many years - using literally the same Yubikey to do it - and even though Microsoft owns both services I'd have to give away the connection by some other means (e.g. linking them both on my HN about box, just using my public IP addresses not Tor or VPNs) or there's no practical way they'd be able to connect the dots.
The idea of walking up to a lock and saying “here are all of my keys. Do any unlock you?” is kind of weird and backwards. But I realize, thinking about it, I was doing that all the time at a previous job where I’d just mash my entire wallet against the keycard reader. Bonus tangent: join me in playing “Payment Roulette” where you mash your wallet against payment terminals and let your credit and debit cards sort out…
ssh is only flashing the "name" printed on each key and asking if it should try one of them. (not exactly but it's more equivalent)
As in if someone pings your server and you get a key that matches their GitHub is it really that person's key or could they be doing it without having the corresponding private key?
Earlier quoted context omitted.
Seems questionable on Github's part to have .keys public by default, why not allow people to opt in ex: keybase.io equivalent? Yes I get that its not sensitive information, but as this demo demonstrates it can fingerprint people who might not be unaware re: this quirk of SSH's coupled with this part of the Github API.
If you are SSH'ing into a server you should expect to get fingerprinted.
When I SSH into a server, I want to be "fingerprinted" as far as I share, any Device fingerprinting allowed by SSH is a security risk to the client.