5 ms·

> Another interesting side effect is that my ssh negotiation is much faster on high latency connections after the hardening. why?

LinuxBender 4y ago
Watching the connection in verbose it appears the cipher list from both the client and server side being significantly shorter and matching on both sides speeds up the negotiation. There may also be other factors but that is what sticks out to me. I've not dug deep enough into this to see if utilizing different ciphers is also part of the speed-up.
- chickin 4y ago
  Initially it sounded implausible that a small size increase could noticably raise connection establishment, but it's possible the small size increase causes MTU to be exceeded, and thus an additional roundtrip.
- newaccount74 4y ago
  RFC 4253 says about the key exchange: > Each side MAY guess which algorithm the other side is using, and MAY send an initial key exchange packet according to the algorithm, if appropriate for the preferred method. If you only support one method, that guess will always be correct, and you save a round trip.
  - deleted 4y ago
    [deleted]
loeg 4y ago
Fewer roundtrips to exchange less data, multiplied by the latency per round trip => lower total time.
mkj 4y ago
Is it a slow bandwidth connection as well as low latency? It could be because curve25519/ed25519 are smaller packet sizes than other algorithms (and also just the length of the list of algorithms in the kexinit packet). I would have expected the round trip count at the SSH level to be the same, but there could be more TCP round trips for window adjustment. Plugging my own software, Dropbear's dbclient is a bit quicker at high latency - "ssh git@github.com" is 3 seconds (from Perth, Australia) vs 1.5 secs with dbclient. It makes use of the "guess kex" feature that most clients don't, and sends other packets sooner. Of course dbclient doesn't have all the useful features of OpenSSH, and isn't as performant at high bandwidth.

LinuxBender 4y ago

Watching the connection in verbose it appears the cipher list from both the client and server side being significantly shorter and matching on both sides speeds up the negotiation. There may also be other factors but that is what sticks out to me. I've not dug deep enough into this to see if utilizing different ciphers is also part of the speed-up.

chickin 4y ago
Initially it sounded implausible that a small size increase could noticably raise connection establishment, but it's possible the small size increase causes MTU to be exceeded, and thus an additional roundtrip.
newaccount74 4y ago
RFC 4253 says about the key exchange: > Each side MAY guess which algorithm the other side is using, and MAY send an initial key exchange packet according to the algorithm, if appropriate for the preferred method. If you only support one method, that guess will always be correct, and you save a round trip.
- deleted 4y ago
  [deleted]

loeg 4y ago

Fewer roundtrips to exchange less data, multiplied by the latency per round trip => lower total time.

mkj 4y ago

Is it a slow bandwidth connection as well as low latency? It could be because curve25519/ed25519 are smaller packet sizes than other algorithms (and also just the length of the list of algorithms in the kexinit packet). I would have expected the round trip count at the SSH level to be the same, but there could be more TCP round trips for window adjustment. Plugging my own software, Dropbear's dbclient is a bit quicker at high latency - "ssh git@github.com" is 3 seconds (from Perth, Australia) vs 1.5 secs with dbclient. It makes use of the "guess kex" feature that most clients don't, and sends other packets sooner. Of course dbclient doesn't have all the useful features of OpenSSH, and isn't as performant at high bandwidth.