openssh bugs - Jan 2024 - [Bug 3653] New: ConnectTimeout causes issue when connecting to an host via tsocks

https://bugzilla.mindrot.org/show_bug.cgi?id=3653

            Bug ID: 3653
           Summary: ConnectTimeout causes issue when connecting to an host
                    via tsocks
           Product: Portable OpenSSH
           Version: 9.6p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: agostino.sarubbo at gmail.com

Dear openssh developers,

in this issue (that is a bit hard to explain and then replicate) we
have three actors:
- an ssh/sshd in an home connection behind nat (home/10.10.0.1)
- a public sshd server
- a ssh client

To have a way to reach my home connection when I'm outside, I do from
home connection something like:
ssh -C -N PUBLIC_SERVER -R 29022:127.0.0.1:22

To reach home from a client when I'm outside I'm doing:
ssh -D1080 -A -J PUBLIC_SERVER root at 127.0.0.1 -p29022

then, I'm logged in into the device at home/10.10.0.1

So at this point, if I want to reach a device into the 10.10.0.1/24
network I'm doing (with tsocks):

export LD_PRELOAD="/lib64/libtsocks.so"
export all_proxy="socks5://127.0.0.1"
ssh 10.10.0.2

and it always worked for me.


At some point(recently) while the connection to home/10.10.0.1 worked
as usual, I was not able to connect to 10.0.0.2 with an output like:

ssh root at 10.10.0.2 -vvvv
OpenSSH_9.6p1, OpenSSL 3.0.12 24 Oct 2023
debug1: Reading configuration data /home/ago/.ssh/config
debug1: /home/ago/.ssh/config line 1: Applying options for *
debug3: kex names ok:
[curve25519-sha256 at libssh.org,diffie-hellman-group-exchange-sha256]
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: resolve_canonicalize: hostname 10.10.0.2 is address
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve;
disabling
debug1: auto-mux: Trying existing master at
'/home/ago/.ssh/socket-root at 10.10.0.2:22'
debug1: Control socket "/home/ago/.ssh/socket-root at 10.10.0.2:22"
does
not exist
debug3: channel_clear_timeouts: clearing
debug3: ssh_connect_direct: entering
debug1: Connecting to 10.10.0.2 [10.10.0.2] port 22.
debug3: set_sock_tos: set socket 3 IP_TOS 0x48
debug2: fd 3 setting O_NONBLOCK
debug1: fd 3 clearing O_NONBLOCK
debug1: Connection established.
debug3: timeout: 30000 ms remain after connect
debug1: identity file /home/ago/.ssh/id_rsa type 0
debug1: identity file /home/ago/.ssh/id_rsa-cert type -1
debug1: identity file /home/ago/.ssh/id_ecdsa type -1
debug1: identity file /home/ago/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/ago/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/ago/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/ago/.ssh/id_ed25519 type -1
debug1: identity file /home/ago/.ssh/id_ed25519-cert type -1
debug1: identity file /home/ago/.ssh/id_ed25519_sk type -1
debug1: identity file /home/ago/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/ago/.ssh/id_xmss type -1
debug1: identity file /home/ago/.ssh/id_xmss-cert type -1
debug1: identity file /home/ago/.ssh/id_dsa type -1
debug1: identity file /home/ago/.ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_9.6
kex_exchange_identification: Connection closed by remote host
Connection closed by 127.0.0.1 port 1080

Note that the three actors in this issue run OpenSSH_9.6p1, so since it
worked for me in the recent past I started to think that was a recent
issue with the OpenSSH_9.6p1 update (I was running 9.5 before), so I
downgraded but the problem still persisted.

At this point I started to play with ssh config on the client, to check
if there is an issue there.
After completely remove my .ssh/config I noticed that connection to
10.10.0.2 worked again so I enabled again my config but at this time I
did it line-by-line to discover the culprit.
Surprisingly it was ConnectTimeout (set to 30), so while 30 seconds are
enough I decided to increase that number to 30000 (when I did it,
client log said: debug3: timeout: 30000000 ms remain after connect) to
check if it works and it didn't.

So in the end while it tooks few ms to connect, and I does not go in
timeout (as log says) for unknown reason, when ConnectTimeout is
declared, connection to 10.10.0.2 (via tsocks obviously) it does not
work.

For completeness, this is my .ssh/config

Host *
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null
    LogLevel ERROR
    ConnectTimeout 30
    KexAlgorithms
curve25519-sha256 at libssh.org,diffie-hellman-group-exchange-sha256
    MACs
hmac-sha2-512-etm at openssh.com,hmac-sha2-256-etm at openssh.com,umac-128-etm
at openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128 at openssh.com
    Ciphers
chacha20-poly1305 at openssh.com,aes256-gcm at openssh.com,aes128-gcm at
openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
    ServerAliveInterval 10
    ControlMaster auto
    ControlPersist 5m
    ControlPath ~/.ssh/socket-%r@%h:%p
    PubkeyAcceptedKeyTypes +ssh-rsa
    #PreferredAuthentications=publickey,password
    AddressFamily=inet
    Protocol 2
    ForwardAgent no

So I can fix my issue by simply commenting ConnectTimeout but I want to
let you know this strange issue.

I run Gentoo, so as a rolling release I suppose that an update of a
package break this behavior but that's not related (at least from my
test) to the openssh update nor the tsocks update (because is dead
upstream and was not touched in the gentoo repo). So I really don't
know.

If I can do further, please let me know.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3653

--- Comment #1 from agostino.sarubbo at gmail.com ---
FTR I get the same behavior via ansible and comment out ConnectTimeout
make it working again:

https://github.com/ansible/ansible/blob/4760dae989c8c86fe67cbcfbf2f11d8f51cda24a/lib/ansible/plugins/connection/ssh.py#L794

-- 
You are receiving this mail because:
You are watching the assignee of the bug.