8

I'm interested in knowing what could be the consequence if the server side SSH keys of a host were compromised.

The situation would be:

  • An attacker manages to read the SSH private keys of the server.
  • The attacker can MITM any connection to the host (because he's controlling the router, or w/e).

Does that mean that any data going trough any SSH connection can now be read by the attacker? I would say no because of some key exchange algorithms like Diffie-Hellman. Is that correct?

My guess would be that the worst an attacker could perform is impersonating the server, leading users to log into his system instead of the legit one.

Xaqq
  • 235
  • 2
  • 9
  • 2
    How did the attacker get the keys? I guess my question is whether the server was compromised or not. – David Houde Apr 04 '14 at 09:35
  • @DavidHoude The attacker had access to the hard drive at some point. (The `/boot` partition holds an ssh server that starts during initramfs, to allow unlocking to `/root` file system remotely). – Xaqq Apr 04 '14 at 09:44
  • 1
    I agree with your analysis of the direct effects of the compromise (no they can't decode the traffic) - further such a scenario would be possible if someone gets hold of a backup. However if the server is compromised then there are lots of other bad things the cracker could do. And I would still consider it good practice to change the key pairs. – symcbean Apr 04 '14 at 10:23

3 Answers3

5

Due to the use of the Diffie-Hellman key exchange, knowing the server's private key does not help a passive-only attacker. If the attacker wants to learn the data, then he must go active.

If the attacker knows the server private key, then he can impersonate the server, i.e. run a fake server and let users connect to it. For a full Man-in-the-Middle attack, the attacker must do a double impersonation: as a fake server when talking to the genuine client, and as a fake client when talking to the genuine server. If the server uses password-based authentication, then this is easy: the client will send his password to the fake server, at which point the attacker knows it and uses it. If the server expects a key-based authentication from the client, this won't work.

However, chances are that a fake server (non-MitM) can fool a client and learn secrets without going full MitM.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • 1
    If I understand things right (and please correct me if I'm wrong), then this answer is nearly right, but also dangerously incomplete. An important caveat is that if the client uses agent forwarding, and logs into a server which is impersonating the real one, then that fake server can complete the connection to the live server and listen in. – mc0e Oct 31 '14 at 13:54
2

If the client initially starts a connection with the correct server, then no, the attacker can't do anything against that connection, but if the attacker can get the user to attach to them instead, then they can play the middle man and make a connection with the client and a separate connection with the server as long as client certificates are not being used.

If the client is using a certificate as well however, then the attacker has a problem as they won't be able to complete the authentication with the real server as the client without also having the client's private key. This is because the session key exchange requires knowing the portion of the key created by both the client and the server. If the real server encrypts its portion of the session key with the client's private key, then it is impossible for the MITM to complete the session key to talk with the real server and it can't function as a MITM, just a stand in for the real server.

If the MITM is able to capture the first time a client makes a connection at all however, it can convince the server that the key pair it generates is actually the client and then it can successfully MITM a client key, but this only works if the real server does not have prior knowledge of the client's public certificate.

AJ Henderson
  • 41,816
  • 5
  • 63
  • 110
  • Not sure what you are talking here about. Using the SSH server side private key an attacker can "impersonate" the server. It doesn't matter whether or not the connection is "initial" or not. I don't see what the client "certificate" changes about this situation, because it is the client's public key that is "registered" on the server, e.g. you should assume it is public knowledge. – Karol Babioch Apr 04 '14 at 14:13
  • @KarolBabioch - I am saying the same thing as Thomas. An attacker with a private key of the server can not passively attack an existing connection between a client and the real server. (In other words, if the client connects to the correct server when initiating the session, then the false server can't monitor that connection or interrupt it because they don't have the session key.) The client certificate matters because the server will recognize if the client certificate is valid for the user being accessed. The MITM would need to be able to respond to the server's challenge for the user. – AJ Henderson Apr 04 '14 at 14:26
  • @KarolBabioch - to further clarify on the client certificate part (since you don't seem to have understood it from either my answer or Thomas') When using client certificates, the client has a private key that corresponds to the public key given to the server. Unless the MITM is able to intercept the very first time that the client authenticates with the server, the server will already know the public key that corresponds with the client. – AJ Henderson Apr 04 '14 at 14:37
  • The MITM won't be able to decrypt the real server's portion of the key exchange, so it can't complete the connection with the real server since you need to know both the portion of the session key you generate and the portion of the key that the other system generates and the attacker has no way to get the part the real server generated without the client's private key. – AJ Henderson Apr 04 '14 at 14:42
0

My guess would be that the worst an attacker could perform is impersonating the server, leading users to log into his system instead of the legit one.

This actually means that attacker can read traffic, acting as proxy.

Question is: will key-based authentication have some positive effect for client

Answers of that question covering that in some details

Community
  • 1
MolbOrg
  • 139
  • 4
  • As Thomas Pornin has pointed out he actually can't read anything until he performs an active attack. This doesn't become clear from your answer. Referring to other answers might be useful, but shouldn't be all your answer is about. – Karol Babioch Apr 04 '14 at 14:11
  • @KarolBabioch I would post that like comment in discussion on question - but rep is low. Originally I wished to answer to @symcbean comment. Thomas Pornin definitely described situation better, but attacker already MITM capable, no reasons for him not to use that. Thomas Pornin conclusion `If the server expects a key-based authentication from the client, this won't work.` needs to be explained - that explanation is't obvious. AJ Henderson pointed, that without forcing client to reconnect, attacker have no advantage by owning server keys. – MolbOrg Apr 04 '14 at 14:37