0

Lyrics

Usually, people say, that using single public key on several servers is just as secure as using unique public keys on each of them. (If we're not talking about possibility of private key being compromised)

But... I don't get, if it's possible to "spoof your authentication" in the following case:

Preconditions

Suppose you're a happy owner of PC-1. There's also a Server-1 and Server-2, and they share the same public key. Server-1 is aware of existence of Server-2, but you don't want Server-1's admin to be able to steal your data from Server-2.

So, what's wrong here:

  1. PC-1 tries to connect to Server-1...
  2. Server-1 provides PC-1 with Server-1's fingerprint (which is known and trusted)
  3. Server-1 "tunnels" authentication request from PC-1 to Server-2
  4. Server-2 replies to Server-1 (sends a "challenge")
  5. Server-1 tunnels challenge to PC-1
  6. PC-1 thinks that "challenge" was generated by Server-1
  7. PC-1 uses it's private key to solve the challenge and sends the signature to Server-1
  8. Server-1 uses obtained signature to authenticate itself on Server-2

PS:

All I know about ssh authentication process came from here and here.

Improve this question
4
  • 2
    I think you're confusing client-side keys and server-side keys. Server-side keys (the ones in /etc/ssh/) will be different for server-1 and server-2, so the fingerprints for server-1 and server-2 will differ as well and therefore there can't be transparent "tunnelling".
    – mricon
    Jan 17, 2013 at 22:25
  • @mricon Fingerprints are only used to compare them with "known_hosts" contents, aren't they? So, on step-2, PC-1 receives Server-1's fingerprint, and it's happy with that. Since it's trying to connect to Server-1. But what next?
    – Igor
    Jan 18, 2013 at 7:42
  • The known_hosts file not only lists the known fingerprints, but also the DNS names and IP addresses these fingerprints belong to. If you try to connect to server-1, but it gives you server-2's fingerprint, SSH will give you a warning. Moreover, it doesn't really matter if traffic passes via server-1 -- you're encrypting the contents of the traffic with server-2's key, so all the MITM party will see is encrypted traffic which they can't decrypt without having server-2's private key.
    – mricon
    Jan 18, 2013 at 14:13
  • @mricon, 1)In my example Server-1 provides PC-1 with Server-1's fingerprint (and it is known by PC-1, because it is known server) 2) the thing is, authentication and data encryption are always described as separate processes...If you're interested, please, see a re-post of the same question on security.stackexchange.com
    – Igor
    Jan 21, 2013 at 21:54

2 Answers 2

Reset to default
0

From the OpenSSH hand book, we have this in section 15.10.3:

SSH utilizes a key fingerprint system for verifying the authenticity of the server when the client connects. The user is prompted to enter yes only when connecting for the first time. Future attempts to login are all verified against the saved fingerprint key. The SSH client will alert you if the saved fingerprint differs from the received fingerprint on future login attempts.

So, if you have logged into Server-2 in the past, an attacker on Server-1 will be revealed because Server-2's fingerprint stored in the client will not match what Server-1 is presenting.

If you have not logged into Server-2 in the past, then it may be possible for Server-1 to perform the man-in-the-middle attack. It may also be possible if you run ssh client with some options that tell it not to check the server fingerprint, but you would have to go out of the way to do this.

Improve this answer
9
  • 1) The question assumes that both fingerprints of Server-1 and Server-2 are known. 2) When PC-1 is connecting to Server-1 he is expecting to receive Server-1's fingerprint, not Server-2's. And Server-1 would kindly provide PC-1 with required fingerprint... That's why my question is called "spoofing-by-known-server"
    – Igor
    Jan 18, 2013 at 7:23
  • I think you're misunderstanding how authentication works in a public key setting, such as used by SSH. Server-1 may have Server-2 public key (which is what you're assuming), but Server-1 does not have Server-2's private key.
    – cjc
    Jan 18, 2013 at 19:08
  • Yes, I think I'm misunderstanding something, but I'm not sure what... Why Server-1 may need Server-2's private key? PC-1 don't have Server-2's private key either, but it's able to connect to Server-2...
    – Igor
    Jan 18, 2013 at 21:51
  • Everyone presents their public keys. Everyone keeps their private keys secret. Server-2 generates a random number (a secret), encrypts it with the private key and sends the secret and its encrypted version to PC-1. The way public key encryption works, only the holder of Server-2's private key can encrypt it so that it decrypts successfully with the corresponding public key (which PC-1 knows belongs to Server-2). When PC-1 decrypts the ciphertext and compares it to the secret, it knows that it is talking to Server-2. Server-1 can't fake it since it doesn't have Server-2's private key.
    – cjc
    Jan 18, 2013 at 22:19
  • That actually isn't how SSH's public key authentication works -- they're doing something more sophisticated -- but you can see how public key cryptography allows parties to know that they are talking to the right counterparty and not the man-in-the-middle, provided that they know that a given public key is correctly associated with the given party. If you want more details, you can ask the other StackExchange site, security.stackexchange.com. I'm sure Wikipedia's article on public key encryption should be detailed, also.
    – cjc
    Jan 18, 2013 at 22:21
0

I've answered my own question on security.stackexchange.com.

The main idea is - in ssh v2 symmetric encryption's shared secret is verified during authentication too, although this is not that obvious.

Improve this answer

You must log in to answer this question.

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