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.

Community
  • 1
Igor
  • 141
  • 6
  • 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 '13 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 '13 at 07: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 '13 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](http://security.stackexchange.com/questions/29440/ssh-reusing-public-keys-and-known-man-in-the-middle) – Igor Jan 21 '13 at 21:54

2 Answers2

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.

cjc
  • 24,533
  • 2
  • 49
  • 69
  • 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 '13 at 07: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 '13 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 '13 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 '13 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 '13 at 22:21
  • I think you misunderstood the situation... In my example **PC-1** is thinking, that it's talking to **Server-1**, **Server-1** may have **Server-2**'s public key, as well as **PC-1**, so, **Server-1** may decrypt data sent by **Server-2**, encrypt it with **Server-1**'s key, and send to **PC-1** to make **PC-1** think that challenge was generated by **Server-1**, while in fact it was generated by **Server-2**. >>provided that they know that a given public key is correctly associated with the given party. The thing is, in my example, **PC-1**'s user uses singe public key for both servers.. – Igor Jan 19 '13 at 09:31
  • That doesn't matter: Server-1 *cannot* fake traffic from Server-2 in a way that fools PC-1. It therefore *cannot* fake the handshake between PC-1 and Server-2. Really, if you want, go post the question to security.stackexchange.com. Someone there will be expert in how SSH works, and will explain it better than me. – cjc Jan 19 '13 at 10:23
  • I agree that there's no real vulnerability,I just misunderstood something, but I just don't know what... Thanks for your suggestion! I've just re-posted my question [here](http://security.stackexchange.com/questions/29440/sshreusing-public-keys-and-known-man-in-the-middle). I've also tried to make it as detailed as possible... – Igor Jan 21 '13 at 16:22
  • I think [I've found the solution](http://serverfault.com/a/478350/154940)... – Igor Feb 13 '13 at 12:59
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.

Community
  • 1
Igor
  • 141
  • 6