Then I tried *this*:
...
Yes, that's eight times the *same* algorithm (the one that would get
picked if there were no problem at all). Now let's try giving it only
*seven* thumbs-up:
...
[ ... continue to successful connection]
Yeah, that smells like MTU.
Still possible that it's a pMTU detection problem or something alike
it, though, will have to look into the tcpdumps I now have to see
whether that's the case ...
When you have the blocking case, run "ss -i" to see the PMTU;
and/or run "tracepath -p 22 <host>" to diagnose.
Furthermore, you could try to set your own VM's MTU smaller to
see whether that solves the problem.
(Both VMs are CentOS 7.9, the client a "free-range" one, the server a
cloud provider's sub-flavor. There's a handful of VLANs, leased line
uplink to a colo, then an IPsec VPN through the Internet into the
cloud, and finally the usual cloud networking between the two.)
Yeah, lots of PMTU trouble points here inbetween.
If that's the case, you could either run one of the VMs with a
smaller permanent MTU, or set a route-specific MTU ("ip route via mtu").
Good luck!
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
