5 ms·

> I've made a habit of manually checking the public-key when I SSH into a new EC2 instance using PuTTY. It is not obvious how to do this. Existing tooling just

> I've made a habit of manually checking the public-key when I SSH into a new EC2 instance using PuTTY. It is not obvious how to do this. Existing tooling just isn't set up with it in mind. This is a not necessarily useful if you use key auth. The attacker can’t perform an useful MITM attack on the connection no matter what key you accept from the server. At best the attacker could let you log into their server, but presumably you’d notice that you’re logged into the wrong server. I guess there are a few corner cases where this might help, such as blind scp uploads.

MaxBarraclough 6y ago
> The attacker can’t perform an useful MiTM attack on the connection no matter what key you accept from the server. True, thanks to public key crypto. > At best the attacker could let you log into their server This is another way of saying the machine you end up trusting could be under the control of an attacker. So yes, that's a serious concern. > presumably you’d notice that you’re logged into the wrong server Not if it's a fresh Ubuntu instance. Even if not, I'd expect SSH security to answer that definitively, on principle. SSH shouldn't be any sloppier than HTTPS.
- DangitBobby 6y ago
  Maybe I'm being naive here, but if you spin up a new instance and immediately SSH into that via the given public IP, isn't the likelihood that someone could have meaningfully injected themselves between you and that previously unknown IP address vanishingly small?
  - lysium 6y ago
    Just monitor and mitm all ssh connections. It’s really easy.
    - MaxBarraclough 6y ago
      Right. The attacker might have compromised my local network, for instance.
ptx 6y ago
Surely the attacker can serve up an SSH server implementation that forwards the connection to the intended server while recording and/or modifying the decrypted traffic as desired? To the user everything would appear as normal (expect perhaps for some additional latency) but their data would be exposed to the attacker. If there were no way to perform a MITM attack because you would notice that you were connected to the wrong server, the whole system of keys and fingerprints would be pointless. So would the CA system for HTTPS.
- ryanlol 6y ago
  > Surely the attacker can serve up an SSH server implementation that forwards the connection to the intended server while recording and/or modifying the decrypted traffic as desired? To the user everything would appear as normal (expect perhaps for some additional latency) but their data would be exposed to the attacker The attacker can’t do this because the attacker does not have your private key. If the attacker proxies your authentication to the remote server, they’ll only be back to square one as the connection is now encrypted with keys the attacker does not hold. This is only possible if you use password auth. > If there were no way to perform a MITM attack because you would notice that you were connected to the wrong server, the whole system of keys and fingerprints would be pointless. So would the CA system for HTTPS. It’s much easier for an attacker to create a malicious copy of a website they have access to than a server they don’t. The phishing opportunities offered by a SSH mitm attack like this are rather limited.
  - MaxBarraclough 6y ago
    > This is only possible if you use password auth. It's not possible with password auth, either. If you check the server's SSH fingerprint on first connection, you're safe from man-in-the-middle attacks, regardless of how you authenticate the user. If you fail to check the server's fingerprint (the way most people use SSH), then you haven't verified the identity of the server, and again this is regardless of how you authenticate the user. There are other advantages to using a public key to authenticate the user, though. [0] [0] https://security.stackexchange.com/a/69408 https://security.stackexchange.com/a/69408

MaxBarraclough 6y ago

> The attacker can’t perform an useful MiTM attack on the connection no matter what key you accept from the server. True, thanks to public key crypto. > At best the attacker could let you log into their server This is another way of saying the machine you end up trusting could be under the control of an attacker. So yes, that's a serious concern. > presumably you’d notice that you’re logged into the wrong server Not if it's a fresh Ubuntu instance. Even if not, I'd expect SSH security to answer that definitively, on principle. SSH shouldn't be any sloppier than HTTPS.

DangitBobby 6y ago
Maybe I'm being naive here, but if you spin up a new instance and immediately SSH into that via the given public IP, isn't the likelihood that someone could have meaningfully injected themselves between you and that previously unknown IP address vanishingly small?
- lysium 6y ago
  Just monitor and mitm all ssh connections. It’s really easy.
  - MaxBarraclough 6y ago
    Right. The attacker might have compromised my local network, for instance.

ptx 6y ago

Surely the attacker can serve up an SSH server implementation that forwards the connection to the intended server while recording and/or modifying the decrypted traffic as desired? To the user everything would appear as normal (expect perhaps for some additional latency) but their data would be exposed to the attacker. If there were no way to perform a MITM attack because you would notice that you were connected to the wrong server, the whole system of keys and fingerprints would be pointless. So would the CA system for HTTPS.

ryanlol 6y ago
> Surely the attacker can serve up an SSH server implementation that forwards the connection to the intended server while recording and/or modifying the decrypted traffic as desired? To the user everything would appear as normal (expect perhaps for some additional latency) but their data would be exposed to the attacker The attacker can’t do this because the attacker does not have your private key. If the attacker proxies your authentication to the remote server, they’ll only be back to square one as the connection is now encrypted with keys the attacker does not hold. This is only possible if you use password auth. > If there were no way to perform a MITM attack because you would notice that you were connected to the wrong server, the whole system of keys and fingerprints would be pointless. So would the CA system for HTTPS. It’s much easier for an attacker to create a malicious copy of a website they have access to than a server they don’t. The phishing opportunities offered by a SSH mitm attack like this are rather limited.
- MaxBarraclough 6y ago
  > This is only possible if you use password auth. It's not possible with password auth, either. If you check the server's SSH fingerprint on first connection, you're safe from man-in-the-middle attacks, regardless of how you authenticate the user. If you fail to check the server's fingerprint (the way most people use SSH), then you haven't verified the identity of the server, and again this is regardless of how you authenticate the user. There are other advantages to using a public key to authenticate the user, though. [0] [0] https://security.stackexchange.com/a/69408 https://security.stackexchange.com/a/69408