SSH is probably one of the most used protocols world-wide and daily used by developers and administrators. But have you ever thought about what your SSH connection might tells about you?
This proof of concept server will warn you about the issue. The address is:
OpenSSH is designed to authenticate you. In order to do this, it’ll send over a public key which can proof that you own the corresponding private key. But before going wild and try everything, your OpenSSH client will send a list of public keys it’s aware of. The server then selects a key it knows and requests that you proof you have this private key.
Obviously this means you have a unique identifier, which is kind of the point of authentication. Just that Public keys are sometimes actually public. For example my public keys can be found at: https://github.com/SISheogorath.keys And that again means that if you ever happen to authenticate to a public server, they are able to identify other profiles of you and track you around the web.
You might think, you are smart, because you use dedicated keys for Github and other public services. But when you didn’t further configure your OpenSSH client, you still expose all of your keys, due to OpenSSH’s default settings.
The good news first, there is an easy way to fix the problem. The bad news, it’s more than just one setting.
If you don’t have it yet, you should create a file called
~/.ssh/config on your system. This is your personal OpenSSH client configuration. There you can specify identity keys to use for certain hostnames. But also other details like usernames, timeouts, etc. basically everything you never want to type again as options to the client connection command. A minimal example for the identity key and username looks like this:
Host *.shivering-isles.com User sheogorath IdentityFile ~/.ssh/id_shivering-isles Host * User root IdentityFile ~/.ssh/id_ed25519
What this example would do: If I connect to any host which has a hostname matching
*.shivering-isles.com, it would use the username
sheogorath automatically and the identity file (private key) located at
~/.ssh/id_shivering-isles. While for all other hosts it would connect as root and using the default
But there is a catch: When you use the configuration above with an ssh-agent, as already mentioned, all servers would still be informed about the public key corresponding to
~/.ssh/id_shivering-isles. To prevent this leak, the setting
IdentitiesOnly yes has to be set as well. This will tell OpenSSH to only send the specified identity instead of all in your ssh-agent’s keyring.
With a separate key for GitHub as well, a more private OpenSSH configuration would look like this:
Host *.shivering-isles.com User sheogorath IdentityFile ~/.ssh/id_shivering-isles IdentitiesOnly yes ForwardAgent no Host github.com User git IdentityFile ~/.ssh/id_github IdentitiesOnly yes ForwardAgent no Host * User root IdentityFile ~/.ssh/id_ed25519 IdentitiesOnly yes ForwardAgent no
As you might notice, I also added
ForwardAgent no to all those settings, in order to prevent agent forwarding. Why it is a problem and why you should avoid agent forwarding, can be read in this little blog post about the Matrix.org incident in 2019.
With those configuration options set, you should no longer be identified by your key publicly available on Github, when you connect anything else than Github itself. Keep in mind that this applies for Gitlab and Gitea as well. All those platforms expose your public keys.
While public keys are made to be public and this entire “problem” is just a privacy, but not a security issue, it highlights that a not properly setup SSH client setup, can leak a lot more information about you, than you might expect.
For most people it might not be that problematic but keep in mind that this also applies to people use platforms like Github to express themselves when they are unable to do this in their country. There is a possibility that governments would start to collect those information and use it to identify people, who felt anonymous on those platforms.
Therefore be careful with your SSH configurations and put some work into them. It’s a few lines, but who knows, they might save your life one day.