ssh whoami.filippo.io(words.filippo.io) |
ssh whoami.filippo.io(words.filippo.io) |
IdentityFile ~/.ssh/keys/%h
See also https://try.popho.be/ssh-keys.html , discussed: https://news.ycombinator.com/item?id=32510475IdentityFile ~/.ssh/some.key
Also, maybe don't trust the SSH config defaults on whatever host you're on at the moment. You can explicitly set defaults yourself in your `~/.ssh/config` or similar.
And how to configure your ssh agent to confirm with you on each use. See `-c` in `ssh-add(1)`, and make sure you're using an agent that supports it (GNOME's Seahorse doesn't, gpg-agent does, macOS's ssh-agent doesn't make can be made to via some AppleScript).
Because my ssh agent confirms each key use, I enable agent forwarding on every ssh connection without fear.
Are they enabled by default when running SSH?
Host *
PubkeyAuthentication no
Put that at the bottom of the file, then turn back on for each host: Host site.com
PubkeyAuthentication yes^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, this config option does not completely prevent pubkey auth being used (i.e. if configured or overriden on the command line). But if you only use that config by itself, it will disable pubkey authentication for every host.
Nothing about that config snippet precludes using private keys for known servers.
I explicitly list every server that I want to connect to in the config file, so I know exactly what is going to happen.
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.
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.
ssh-import-id gh:$USERNAMEAge (the author's file encryption tool) can make use of this when encrypting a file to send to someone.
* github.com * sourcehut (sr.ht) * gitlab.com * codeberg.org * ...
published ssh keys & changes, to verify (offline) ssh signed commits, verify, encrypt mails, exchchange secure data (age-enc).
You can use this app:
[] https://github.com/paepckehh/gitkeys
If you want your own repos public keys tracked / monitored / archived, just leave a star:
Not sure about other systems, but this isn't the default on Debian. I, at least, start every day by running `ssh-add ~/.ssh/id_whatever_service_I_want_to_auth_to`, because it doesn't do it by itself, and I was too lazy to configure it. For the same reason, the party trick didn't work here, since I haven't had to commit anything today yet ...
age (another tool of Filippo's) leverages this to make encrypting to any GitHub user easy[1].
[1]: https://github.com/FiloSottile/age#encrypting-to-a-github-us...
I made https://sshign.tcardenas.me/ to take advantage of this. For example: [1]
In the end, it isn't that useful. I only routinely sign digitally to deal with the (Spanish) government, and they provide their own certificates and software to do that.
[1] https://sshign.tcardenas.me/?signer=github.com%2Ftcard&messa...
ssh whoami.filippo.io
cannot find any of my keys on Github, even though I have the Github key in my ~/.ssh folderAs 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?
Edit: totally disregard this, absolute brain fog moment
$ ssh whoami.filippo.io
+---------------------------------------------------------------------+
| |
| _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 them to lookup your GitHub account, |
| but got no match :( |
| |
| -- Filippo (https://filippo.io) |
| |
| |
| P.S. The source of this server is at |
| https://github.com/FiloSottile/whoami.filippo.io |
| |
+---------------------------------------------------------------------+
Of course, this happens because the day I learned about the default behavior of SSH (to send all your keys in hope that one works), I went ahead to disable it to stop remote servers from being able to inspect all my keys. I feel this can be abused in a similar way that sites abuse browser information to fingerprint users. So I put this at the bottom of ~/.ssh/config: Host *
IdentitiesOnly yes
And then I explicitly indicate what key to use for each server, either with the "-i" argument, or adding entries above the previous lines: Host example.com
IdentityFile ~/.ssh/example.com.pem
Other commenter mentioned that something similar can be achieved with "PubkeyAuthentication no", but I've been using "IdentitiesOnly yes" for years without issue.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 which is going to pay.
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)
$ ssh whoami.filippo.io
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: POSSIBLE DNS SPOOFING DETECTED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The ED25519 host key for whoami.filippo.io has changed
I guess I've tried this beforeWhen 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.
Is it just as OP states in article, where you have to interact with the authentication process to provide a key (assuming no key is associated to host as you explain)?
If you only SSH into servers you trust (a sensible practice) then the benefit is marginal.
That you trying to SSH into some random server doesn't know that you also use github?
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.
The signature verification is handy.
I value this and I universally disable password auth…on the server :)
E: as listed by others, IdentitiesOnly=yes seems like a better approach?
You can also use placeholders for keys, so for example I have a ssh config like:
Host *.mycompany.com
# Employer specific yubikey stuff
Host *.mydomain.com
IdentityFile ~/.ssh/keys/id_primary
Host *
IdentitiesOnly yes
IdentityFile ~/.ssh/keys/%r@%h # uses ~/.ssh/keys/git@github.com for github for example
I originally started doing this because I would have so many keys that servers would reject me for too many authentication attempts, but it also helps make it easy to use distinct keys for distinct purposes and avoiding fingerprinting like this*This kind of stuff is also useful, for example, for AWS machines:
Host ec2-*.compute-1.amazonaws.com
# KeepAlive of 50 seconds, because AWS times out after 60:
# https://aws.amazon.com/blogs/aws/elb-idle-timeout-control/
ServerAliveInterval 50Host foo foo.example.com some.other.alias