6

Suppose I'm about to connect to a new (unauthenticated to me) server. I've previously provided my ssh public key to the server owner (who populates it in the appropriate authorized_keys file). The server owner can't securely provide me with the host public key information in advance and says that as long as my public key is known only to us, security will be maintained.

Other than the case where a rogue server also/already has my public key, is there any chance I might divulge my credentials (or otherwise compromise security) if my ssh session to this unauthenticated server is (from the beginning) directed to a rogue server (e.g., one acting as MiTM)? Some of the answers here seem to suggest that there is a potential issue--perhaps depending on the version of SSH used?

jhfrontz
  • 223
  • 1
  • 5
  • 3
    No, this is not safe, see [here](https://security.stackexchange.com/a/189454/151903). Authenticating with an ssh key _requires_ that you **send them the public key**. You should **never** assume that a public key is private. – AndrolGenhald Sep 06 '18 at 14:59
  • @AndrolGenhald thanks-- if you make this an answer, I'll upvote/accept. – jhfrontz Sep 06 '18 at 15:16
  • I think it's similar enough I'll actually just suggest it as a duplicate. – AndrolGenhald Sep 06 '18 at 15:18
  • 5
    Possible duplicate of [Does git use the ssh user keys or the repository's deploy keys for encryption?](https://security.stackexchange.com/questions/189445/does-git-use-the-ssh-user-keys-or-the-repositorys-deploy-keys-for-encryption) – AndrolGenhald Sep 06 '18 at 15:18
  • 1
    @AndrolGenhald I guess conceptually the answer to my question is in the answer to the git one, but I would have never read it because the question (and even the answers) seemed specific to git. – jhfrontz Sep 06 '18 at 15:30
  • It's fairly common to close as duplicate based on an answer answering the question rather than the question being the same, as long as the answer isn't _too_ different. When marked duplicate this question remains with a link to the other question, so someone searching who finds this one can easily find the answer. – AndrolGenhald Sep 06 '18 at 15:38
  • @AndrolGenhald OK -- if there are no other risks in this scenario (i.e., other than the fallacy that the "secret" client public key can be used to verify the server's identity), then I'll click the "solved my problem". – jhfrontz Sep 06 '18 at 15:49
  • 1
    @AndrolGenhald - Why is it not safe? The answer you linked just says "don't assume public keys are private" Connecting to a rogue SSH server using key auth does not give away your private key and does not allow that rogue server to impersonate you – paj28 Sep 06 '18 at 16:13
  • 1
    @paj28 OP wants to authenticate the server, and it was suggested that since only he and that server know his public key, no further authentication would be necessary. It's not about giving away your private key, it's about assuming that a rogue server is the legitimate server. – AndrolGenhald Sep 06 '18 at 16:16
  • 1
    @AndrolGenhald maybe I should divide this into two questions: 1) can client public key be used to authenticate server and 2) other than making the answer to #1 be "no", is there any harm in being promiscuous with your authentication attempts (e.g., attempting to authenticate at a known-but-potentially-unfriendly server using the client credentials intended for another server)? – jhfrontz Sep 06 '18 at 16:47

3 Answers3

5

In the comments OP separated his original question into two different questions, the first of which has already been answered, as pointed out in the comments.

Question 1:

can client public key be used to authenticate server

The answer is no. (See, Does git use the ssh user keys or the repository's deploy keys for encryption?).

Question 2:

is there any harm in being promiscuous with your authentication attempts (e.g., attempting to authenticate at a known-but-potentially-unfriendly server using the client credentials intended for another server)?

Harm can mean various things. But, I think OP is asking about whether or not simply trying to authenticate using ssh keys to a rogue server will somehow leak information about his private key (stored only on his client machine).

With this definition of "harm" the answer is no.

When you try to authenticate to a rogue server, you will receive that server's public key (in its certificate). This will allow you to authenticate the server and you will see that it is rogue and not connect. So, this doesn't expose your private key in any way.

But what about the case where you do attempt to connect to the rogue server? Suppose that the rogue server does have your public key. In this case you still don't leak your private key by attempting to connect, since it is your (ssh) public key that is used by the rogue server to authenticate you. The rogue server can send you a challenge encrypted with your public key. Then you can decrypt it with your private key and prove you are who you say you are. You only send back the decrypted challenge, you don't send your private key or any info about your private key. And this should not leak any information about your private key (with the caveat that I'm assuming that modern public key crypto such as RSA and/or ssh is/are not broken).

I would also like to reemphasize that fact that I'm assuming the question is only directed at connection attempts. I'm not considering the fact that a rogue server might spoof a user/pass login and harvest your credentials that way, or some other malicious behavior such as logging your IP for a subsequent retaliatory attack, etc.

hft
  • 4,910
  • 17
  • 32
  • "some other malicious behavior such as logging your IP" -- right, there's a privacy component to "harm". But there's no way for the rogue to actually set up a "T" and monitor communication (save for the quantity/duration) between the client and [intended] server, right? – jhfrontz Sep 06 '18 at 20:02
  • I guess I would say, typically there should be no way... subject to caveats that the user isn't doing something dumb like using the rogue as a proxy somehow.... – hft Sep 06 '18 at 20:30
  • Yeah, maybe that's what I'm vaguely recalling -- that if you are using a proxy, you should be very careful about what credentials you send to/through it (lest they be re-used for some other connection)? – jhfrontz Sep 06 '18 at 20:50
  • I think to more clearly answer or discuss it would be good for you to pose this as a separate new question about privacy components to harm to the forum . – hft Sep 06 '18 at 21:10
3

If you don't have the host key another server can pretend to be the server you are trying to log into. This could be a problem if you send any confidential information over the link before you realise you are logged into the wrong server.

You should also be wary of having X11-forwarding enabled or, worse, ssh-agent forwarding. With ssh-agent forwarding enabled (and a running agent) a rogue server can do a full MitM attack logging you into the real server with your own key and monitoring everything you do there.

Ideally you would use whatever mechanism you trusted to get your key to the sysadmin to also get the host key into your known_hosts before you attempt a connection.

William Hay
  • 592
  • 2
  • 10
1

From your question, it sounds like you're using whether or not the server knows your public key as part of the authentication. You're using a public key as a private secret. The obvious point is "What if you connect to an ssh server that's configured to accept (and log) any public key?".

More generally, any time you're using a security mechanism in a different way than it was intended, this should raise red flags. I'll expand on @AndrolGenhald's quote from this answer:

Public keys are called public for a reason, you should never assume it to be private even if you just generated it to add to GitLab over HTTPS and don't use it anywhere else.

There are ways your public key could get leaked:

  • You could connect to the wrong ssh server by accident, thus sending your public key.
  • When connecting to the real server, the networking hardware in between could be logging traffic, thus logging your public key.
  • On disk, ssh private keys are usually password-encrypted but public keys are not, which leads to greater risk of your public key walking away.
Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207