0

The description of my problem is the following.

I have my work computer, that is always online and has a static IP address. I have my laptop, that I travel around with — obviously, it has no static IP, but I want it to be accessible from outside. So, I open an ssh tunnel from work-comp port 111 to laptop port 222 (command "ssh -nNT -R 111:localhost:222 -p 222 root@work-comp" that is being run on laptop; I have sshd configured to listen port 222). I expect that while doing "ssh -p 111 work-comp", I get redirected to port 222 of my laptop, so the problem get solved.

In fact, it works, but only when I run "ssh -p 111 work-comp" from my work computer. When I try to do this from any other machine, ssh throws "ssh_exchange_identification: read: Connection reset by peer"!

Any ideas how to debug this issue?

Additional info: After some more debugging I've found that this issue happens only when I try to connect from machines of the network I'm currently in. When I try it from machines from the network the work-comp is in (I can connect to some of them remotely), everything's OK. Maybe something happens when identification packets are being transferred from one network to another?

The output of ssh client is:

user@some-machine:~> ssh -vvv -p 111 work-comp
OpenSSH_7.2p2, OpenSSL 1.0.2j-fips  26 Sep 2016
debug1: Reading configuration data /home/<user>/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug2: resolving "work-comp" port 111
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to work-comp [work-comp] port 111.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/<user>/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/<user>/.ssh/id_rsa-cert type -1
debug1: identity file /home/<user>/.ssh/id_dsa type 2
debug1: key_load_public: No such file or directory
debug1: identity file /home/<user>/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/<user>/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/<user>/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/<user>/.ssh/id_ed25519 type 4
debug1: key_load_public: No such file or directory
debug1: identity file /home/<user>/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2
ssh_exchange_identification: read: Connection reset by peer

The output of ssh server (in debugging mode) is:

user@laptop:~> sudo /usr/sbin/sshd -D -ddd
debug2: load_server_config: filename /etc/ssh/sshd_config
debug2: load_server_config: done config len = 624
debug2: parse_server_config: config /etc/ssh/sshd_config len 624
debug3: /etc/ssh/sshd_config:13 setting Port 222
debug3: /etc/ssh/sshd_config:27 setting HostKey /etc/ssh/ssh_host_ed25519_key
debug3: /etc/ssh/sshd_config:54 setting AuthorizedKeysFile .ssh/authorized_keys
debug3: /etc/ssh/sshd_config:72 setting PasswordAuthentication no
debug3: /etc/ssh/sshd_config:106 setting UsePAM yes
debug3: /etc/ssh/sshd_config:110 setting GatewayPorts yes
debug3: /etc/ssh/sshd_config:111 setting X11Forwarding yes
debug3: /etc/ssh/sshd_config:113 setting X11UseLocalhost no
debug3: /etc/ssh/sshd_config:117 setting TCPKeepAlive yes
debug3: /etc/ssh/sshd_config:119 setting UsePrivilegeSeparation sandbox
debug3: /etc/ssh/sshd_config:122 setting ClientAliveInterval 60
debug3: /etc/ssh/sshd_config:123 setting ClientAliveCountMax 3
debug3: /etc/ssh/sshd_config:135 setting Subsystem sftp /usr/lib/ssh/sftp-server
debug3: /etc/ssh/sshd_config:138 setting AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
debug3: /etc/ssh/sshd_config:139 setting AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
debug3: /etc/ssh/sshd_config:140 setting AcceptEnv LC_IDENTIFICATION LC_ALL
debug1: sshd version OpenSSH_7.2, OpenSSL 1.0.2j-fips  26 Sep 2016
debug1: private host key #0: ssh-ed25519 SHA256:<some number>
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-D'
debug1: rexec_argv[2]='-ddd'
debug3: oom_adjust_setup
debug1: Set /proc/self/oom_score_adj from 0 to -1000
debug2: fd 3 setting O_NONBLOCK
debug1: Bind to port 222 on 0.0.0.0.
Server listening on 0.0.0.0 port 222.
debug2: fd 4 setting O_NONBLOCK
debug3: sock_set_v6only: set socket 4 IPV6_V6ONLY
debug1: Bind to port 222 on ::.
Server listening on :: port 222.
debug3: fd 5 is not O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug3: send_rexec_state: entering fd = 8 config len 624
debug3: ssh_msg_send: type 0
debug3: send_rexec_state: done
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from ::1 port 54990 on ::1 port 222
^C

All machines in question have openSUSE 42.3 (x86_64) with OpenSSH 7.2 installed. The authentication is configured to use ed25519 keys.

1

You can probe your tunnels on each system to some degree by running netstat to review the open ports.

For example I've set up a reverse tunnel to test with:

user@computer1:~ $ ssh -nNT -R 12345:localhost:22 computer2

Then I probe the ports on computer2. The flag -l lists only listening ports, the flag -t will show only tcp ports (such as ssh).

user@computer2:~ $ netstat -l -t
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 0.0.0.0:ssh             0.0.0.0:*               LISTEN     
tcp        0      0 localhost:12345         0.0.0.0:*               LISTEN         
tcp6       0      0 [::]:ssh                [::]:*                  LISTEN     
tcp6       0      0 localhost:12345         [::]:*                  LISTEN

From here it's apparent what's wrong with the reverse tunnel: it's only listening on localhost (i.e. the loopback interface). If it were listening on all interfaces I should see 0.0.0.0:12345 for ipv4 and [::]:12345 for ipv6.

When you run ssh -p 111 work-comp from work-comp it accepts the connection from localhost, but when you run the same command from an outside machine work-comp isn't actually listening for connections from 'some-machine' on that port.

You could create another tunnel from 'some-machine' to the correct port of 'work-comp' or use ProxyCommand to connect to 'laptop' through 'work-comp'.

  • Thanks; I've checked ports with netstat, tunnels are listening on all interfaces. After some more debugging I've found that this issue happens only when I try to connect from machines of the network I'm currently in. When I try it from machines from work-comp network, everything's OK. – Dmitry Tsirkov Nov 24 '17 at 16:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.