That is: MITM SSH connections to these devices without getting any warning.
Of course you first have to get in a position to MITM the person who connects to these devices.
Also if the underlying cryptography isn't forward-secure, anyone with the private key can go back and read your recorded SSH sessions, including any kind of secrets that you typed into them (or files that you downloaded with scp or rsync). I don't know under what conditions SSH uses or doesn't use forward-secure key exchange methods.
SSH always (to the extent of my knowledge) uses Diffie–Hellman to generate session keys, and regenerates them at periodic intervals, and so always has forward-secrecy. This only affects the ability to MITM new connections.
You'd still be able to impersonate the server, but that's less useful in the general case unless you can emulate the remote machine convincingly long enough to gather useful information.
I'm not sure what you say is true. On it's face, it doesn't make any sense, if you have completely MiTM's the network connection, and can pass along traffic from each part to the other, I don't see how client key auth would prevent MiTM.
Even the thing you link to actually says:
> The algorithm itself does not protect against active MITM attack, but it makes it impossible for MITM attacker to influence the choice of the shared key (and by extension the session ID) by the victims.
Does not protect against active MITM attack. It _does_ keep an attacker from influencing choice of shared key, but an active MITM attack is still in the middle and doesn't need to influence choice of shared key to mount many many kinds of attacks.
From the very first paragraph of that link: "Should ... an attacker manage to steal the private key ... the connection becomes vulnerable to active man-in-the-middle attacks".
Thus, all these machines with duplicate keys are VERY vulnerable to MITM, because anyone with access to one of them has access to the private key.
schoen|11 years ago
yuriks|11 years ago
jewel|11 years ago
http://www.gremwell.com/ssh-mitm-public-key-authentication
You'd still be able to impersonate the server, but that's less useful in the general case unless you can emulate the remote machine convincingly long enough to gather useful information.
jrochkind1|11 years ago
Even the thing you link to actually says:
> The algorithm itself does not protect against active MITM attack, but it makes it impossible for MITM attacker to influence the choice of the shared key (and by extension the session ID) by the victims.
Does not protect against active MITM attack. It _does_ keep an attacker from influencing choice of shared key, but an active MITM attack is still in the middle and doesn't need to influence choice of shared key to mount many many kinds of attacks.
unknown|11 years ago
[deleted]
shuzchen|11 years ago
Thus, all these machines with duplicate keys are VERY vulnerable to MITM, because anyone with access to one of them has access to the private key.