4 ms·

Not my domain of expertise; can someone explain why this is problematic?

• bbrazil 12y ago
  If you can read the private key from just one of these machines then you can impersonate any of them.
  • 4mnt 12y ago
    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.
    • schoen 12y ago
      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.
      • yuriks 12y ago
        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.
        • schoen 12y ago
          That is great, thank you for the information.
    • jewel 12y ago
      I was surprised to learn that you can't man-in-the-middle an SSH connection if the client is using a key for authentication instead of a password: http://www.gremwell.com/ssh-mitm-public-key-authentication 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.
      • deleted 12y ago
        [deleted]
      • jrochkind1 12y ago
        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.
        • mkj 12y ago
          The pubkey authentication will fail because the signature is over the session key. If there's a MITM going on then each side will see a different session key. Check out the RFCs 4253 and the auth one (425?)
          • deleted 12y ago
            [deleted]
          • johnmaguire2013 12y ago
            I'm confused by this. I know that HTTPS is supposed to be fixing this problem too supposedly. But I don't understand how. If an attacker fully replicates a SSH server, and responds to all client messages with the victim correctly, while then relaying their commands to the real SSH server, and acting as a full SSH client, isn't there still an issue? The attacker just has to authenticate with the correct signature to each, but if it's an attacker, why would it just pass along the victim's data anyway? The whole point of an MITM is that you can modify data before it hits its target.
            • asdfaoeu 12y ago
• deleted 12y ago
  [deleted]