“ssh_exchange_identification: read: Conexão redefinida pelo peer” ao tentar conectar pelo ssh usando uma porta redirecionada via ssh tunnel

Question

A descrição do meu problema é a seguinte.

Eu tenho meu computador de trabalho, que está sempre on-line e tem um endereço IP estático. Eu tenho meu laptop, que eu viajo por aí - obviamente, ele não tem IP estático, mas eu quero que ele seja acessível de fora. Então, eu abro um túnel ssh da porta de compilação de trabalho 111 para porta de laptop 222 (comando "ssh -nNT -R 111: localhost: 222 -p 222 raiz @ work-comp" que está sendo executado no laptop; tenho sshd configurado para escutar porta 222). Espero que ao fazer "ssh -p 111 work-comp", eu seja redirecionado para a porta 222 do meu laptop, para que o problema seja resolvido.

Na verdade, funciona, mas apenas quando eu executo "ssh -p 111 work-comp" do meu computador de trabalho . Quando tento fazer isso de qualquer outra máquina , o ssh lança "ssh_exchange_identification: read: Connection reset by peer"!

Alguma ideia de como depurar este problema?

Informação adicional: Depois de um pouco mais de depuração, descobri que esse problema acontece apenas quando tento me conectar a partir de máquinas da rede em que estou atualmente. Quando eu tento de máquinas da rede, a work-comp está em (posso me conectar a algumas deles remotamente), está tudo bem. Talvez algo aconteça quando os pacotes de identificação estão sendo transferidos de uma rede para outra?

A saída do cliente ssh é:

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

A saída do servidor ssh (no modo de depuração) é:

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

Todas as máquinas em questão têm o openSUSE 42.3 (x86_64) com o OpenSSH 7.2 instalado. A autenticação está configurada para usar chaves ed25519.

    

Answer 1

Você pode investigar seus túneis em cada sistema até certo ponto executando netstat para revisar as portas abertas.

Por exemplo, configurei um túnel reverso para testar:

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

Então sondar as portas no computador2. O flag -l lista apenas as portas de escuta, o sinalizador -t mostrará apenas as portas tcp (como 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

A partir daqui, é evidente o que há de errado com o túnel reverso: ele está apenas ouvindo o host local (isto é, a interface de loopback). Se estivesse escutando em todas as interfaces, eu deveria ver 0.0.0.0:12345 para ipv4 e [::]:12345 para ipv6.

Quando você executa ssh -p 111 work-comp de work-comp, ele aceita a conexão do localhost, mas quando você executa o mesmo comando de uma máquina externa, o work-comp não está realmente atendendo conexões de 'alguma máquina' naquela porta .

Você poderia criar outro túnel de 'alguma máquina' para a porta correta de 'trabalho-comp' ou usar o ProxyCommand para se conectar ao 'laptop' por meio de 'work-comp'.