To make use of one different key per host, you can use some ssh_config(5) magic[0]:

    IdentityFile ~/.ssh/keys/%h

See also https://try.popho.be/ssh-keys.html , discussed: https://news.ycombinator.com/item?id=32510475

[0] https://man.openbsd.org/ssh_config.5

I learned about this when I encountered a server with an aggressive fail2ban that wouldn't let me log in because I had too many ssh keys. It apparently counted every wrong key as an auth attempt, so it blocked me before my ssh client tried the right key. Since then I've used IdentitiesOnly=yes

Before SSH-ing into untrusted hosts, make sure you understand what SSH agent-forwarding and X11-forwarding are.

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.

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

I have been circumventing this issue purely by accident it seems.

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.

Today I learned that GitHub keeps a publicly accessible list of all pubkeys linked to each user's account.

    ssh-import-id gh:$USERNAME

So users can add other users' SSH keys (sourced from GitLab, ....) to their GitHub profile, essentially depriving the actual key owner from using GitHub

If you need a local & offline first tool to log/track/archive changes from all kind of git repos yourself, from:

* 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:

[] https://github.com/paepckehh/keys

> The first is that the SSH protocol provides to the server all public keys the client is willing to produce signatures for, which by default are all the public keys in your ssh-agent and in your ~/.ssh/id_*.

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 ...

I don't know whether this is clever or not. But it ID'd me from my Github account public keys.

I use a different key per host and only send the right key for the host using IdentityFile

  ssh whoami.filippo.io

cannot find any of my keys on Github, even though I have the Github key in my ~/.ssh folder

Can you use this to id people for authentication?

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?

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

The existence of lesser-known things like this, combined with the defaults of SSH clients, and the rabid promotion of keypair auth instead of passwords, really makes one wonder whether there is some ulterior motive to make it easier to deanonymise and thus track users...

Isn't it spelled filippx now? The 'x' signifies 'no'.

Just for those curious about it:

  $ 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.

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 which is going to pay.

  $ 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 before

I think a lot of people in the comments are missing the fact that public keys are by default intended to be public. This is an explicit and intended property of private-public key cryptography. Your public keys are not a security boundary and setting `IdentitiesOnly` in your SSH configuration does not do anything to strengthen your security posture.

You actually were wrong to disregard this entirely although of course having a public key doesn't allow somebody to trick GitHub into thinking they know your private key -- the trick this whoami server is doing could indeed be fooled that way.

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.

How can someone impersonate you?

What, if any, are the downsides to this?

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)?