Your message dated Sun, 24 May 2026 15:13:05 +0100
with message-id <[email protected]>
and subject line Re: Bug#1136816: Acknowledgement (openssh-client: TCP connect
hang in OpenSSH 10.0p2, nc works)
has caused the Debian Bug report #1136816,
regarding openssh-client: TCP connect hang in OpenSSH 10.0p2, nc works
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1136816: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1136816
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: openssh-client
Version: 1:10.0p2-7
Severity: normal
OpenSSH 10.0p2 in Debian Trixie hangs indefinitely on TCP connect()
to any remote host. nc(1) and curl(1) to the same IP:port work
instantly, confirming this is not a network or firewall issue.
Steps to reproduce:
1. ssh -V -> OpenSSH_10.0p2 Debian-7+deb13u2, OpenSSL 3.5.5
2. ssh -vT [email protected]
3. Hangs at: "Connecting to ssh.github.com [140.82.121.35] port 443."
4. Must Ctrl-C after ~30-60s. No error message, just timeout.
Expected result: SSH handshake begins immediately (as with nc/curl).
Actual result: connect() syscall never returns; connection stalls.
Evidence:
- nc -vz github.com 22 -> open (instant)
- nc -vz ssh.github.com 443 -> open (instant)
- curl -I https://github.com -> HTTP/2 200 (instant)
- strace -e trace=network ssh -vT [email protected] shows:
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(443),
sin_addr=inet_addr("140.82.121.35")}, 16) <-- hangs here
Environment:
- Fresh Debian 13 (Trixie) install, kernel 6.12.88+deb13-amd64
- No local firewall: iptables/nftables empty, no proxy env vars
- No AppArmor denials in dmesg
Workaround:
Adding "ProxyCommand nc -q 0 %h %p" to ~/.ssh/config completely
bypasses the bug, confirming the issue is specifically in OpenSSH's
direct socket creation/connect path, not in the network layer.
--- End Message ---
--- Begin Message ---
Source: openssh
Source-Version: 1:10.0p1-7+deb13u4
On Mon, May 18, 2026 at 08:37:08AM +0200, Ezequiel Fernandez wrote:
Confirmed fixed in 1:10.0p1-7+deb13u4.
ssh -T [1][email protected] and git clone now work immediately without any
workaround. The connect() stall is gone.
Thanks for confirming. Closing this bug, then.
Regards,
--
Colin Watson (he/him) [[email protected]]
--- End Message ---
