1

According to the man page, ssh by default sends multiple public keys from files in the ~/.ssh folder, one by one, until authentication success. Does that mean that the server side could know multiple (possibly all of) the client's public keys after a single authentication?

If so, website A would easily know a user's username from website B, if website B publishes public key to username mapping, unless the user specifically narrows down what public key to use when logging into website A.

Is that an intended behavior, or did I miss something here, since I do not know much about this...

4
  • 1
    Yes, this is the case. If this is not what you want, you can specify the exact key which should be used using -i option.
    – George Y.
    Jan 30, 2021 at 6:02
  • "website A would easily know a user's username from website B" - what do websites have to do with SSH? SSH is not used for authentication on websites. Jan 30, 2021 at 8:35
  • 1
    Public key is made to be PUBLIC, it's literally in the name
    – yeah_well
    Jan 30, 2021 at 8:49
  • Also, you don't authenticate to a webserver in ssh, you authenticate to an ssh server
    – yeah_well
    Jan 30, 2021 at 8:51

3 Answers 3

3

Yes that is the behaviour. The problem you highlight is partly caused by, as you said, "[websites publishing] public key to username mapping" -- there is no reason to do that, even though public keys are by definition public.

If you're concerned about that, use a different keypair for every service you use, then in your ssh config add the IdentityFile and IdentitiesOnly directives.

1

Yes it is the intended behaviour. Because you are misunderstanding what ssh is made for: ssh allows to open a remote shell session. That means that is a site allows you to connect with ssh, you are allowed to execute any command there, and the only remaining security is the file system permissions. Said differently there is a very high trust between the server and the client - in many systems, only admins are allowed to use ssh...

As far as I am concerned, I have been using Unix (or Unix-like) systems with ssh for about 30 years, and the various systems that I connected at a time in ssh had the same admin team (in fact never more that 5 admin teams). So I had no reason to hide a public key for a system to the admins of a different system.

Of course, there are real world use cases where you ssh to different and unrelated systems. An example is cloud systems hosted by different organizations. In that case, it really makes sense to declare the key to use when starting a ssh session because there are actually different security zones, and you have no reason to leak an unnecessary information (even if public) for one zone to un unrelated zone.

1

A server can request all public keys from the the ssh agent or during the public key authentication process. This is even possible before the client is requested to authenticate against the server.

This information can be used by the ssh server to choose the user or check if a user with a specific public key exists. For example, if you are connecting to a git server, in most cases you are using the username "git" and not your own.

The git server can request all public keys and search for them in the userdatabase. Without this behaviour it would be inefficient. This info has no reliable source.

From a security perspecitve, there is no problem to send this information to the ssh server, but there is also a privacy aspect.

A server can compare all public keys before you are authenticated, which are available through the agent, to a known list. For example you can get my public key from github: https://github.com/manfred-kaiser.keys

If you have a ssh server an you compare each public key to my key from github, you know when I have tried to login to your server.

This behaviour can also be used for known malicious public keys to block them and alert in case of a break in attempt.

Update 2021-10-27:

As defined in RFC-4252, a client ask the server if a publickey is allowed to login to a specific server (CVE-2016-20012).

If an attacker has some possible usernames and publickeys, it's possible to query the server, if a given combination is allowed to login.

SSH-MITM as an audit tool implemented, which allows you to query the ssh server, if a given username/publickey combination is known by the server:

ssh-mitm audit check-publickey --username usertocheck --public-key path/to/publickey

When running as server, the server collects all publickeys. Those keys can be compared to github (not implemented) or to another server (implemented as part of the authentication process)

Examples:

Client: If a client connects to a tor hidden service, the client send all known/configured keys to the server. The server can compare the publickey to a known list (e.g. publickey on github) and the tor hidden service knowns who you are.

Server: If the tor hidden service is accessible over SSH, CVE-2016-20012 can be used to query if a given username/publickey combination can be used to login to the server. This information can be used to find the administrator of the server, if you know who is the owner of the publickey.

Mitm Attack: Both information leaks can be used by a man in the middle server to find out, which authentication method will be used to login to the remote server.

Disclosure: I'm the author of SSH-MITM. This is an audit tool for ssh and implements the described information leaks to intercept the authentication process.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .