Created attachment 3565 [details] log of the three commands The ConnectTimeout option does not work for me, as you can see from the reports. If I give the command without options I connect immediately. With a timeout of less than 130 seconds, it fails with timeout. With a longer timeout it goes a few more steps but still fails. uname -a Linux DG1600223 4.19.0-16-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19) x86_64 GNU cat /etc/ssh/ssh_config SendEnv LANG LC_* HashKnownHosts yes GSSAPIAuthentication yes cat /root/.ssh/config Host * StrictHostKeyChecking = no UserKnownHostsFile = /dev/null ControlPath none
I think this is bug#3229 which was fixed in the 8.5 release.
(In reply to Darren Tucker from comment #1) > I think this is bug#3229 which was fixed in the 8.5 release. I think they are two different cases
> OpenSSH_7.9p1 Debian-10+deb10u2, OpenSSL 1.1.1d 10 Sep 2019 Firstly, you are using a vendor modified version of OpenSSH. Can you reproduce the problem with the stock source from openssh.com? I can't tell timings from those traces, but the first two are showing two different behaviours from the remote server: > ssh -vvv -o ConnectTimeout=30 -p 443 user@srvsysssh.com [...] > debug1: connect to address 94.86.175.299 port 443: Connection timed out > ssh: connect to host srvsysssh.com port 443: Connection timed out The server fails to establish a TCP connection within 30s. > $ ssh -vvv -o ConnectTimeout=150 -p 443 user@srvsysssh.com > OpenSSH_7.9p1 Debian-10+deb10u2, OpenSSL 1.1.1d 10 Sep 2019 [...] > debug1: Connection established. > debug3: timeout: 29987 ms remain after connect [...] > debug1: Local version string SSH-2.0-OpenSSH_7.9p1 Debian-10+deb10u2 > ssh_exchange_identification: Connection closed by remote host Assuming the transcription is correct, the connection takes ~120s to come up, then the TCP connection is established but the server does not reply to the SSH banner and instead closes the connection after some amount of time I cannot determine (but presumably a bit less than 30 seconds later). The third trace looks ok from what you have shown. Given you're using port 443, is it possible there's a transparent web proxy in the path? or one of those HTTPS/SSH multiplexers? Where are the significant delays and how long are they? FWIW your examples work for me both with the stock OpenSSH and a Debian I happen to have handy (albeit on port 22, which is what the server is on): $ ssh -V OpenSSH_7.9p1 Debian-10+deb10u2, OpenSSL 1.1.1d 10 Sep 2019