ssh para o servidor remoto trava, mas funciona localmente (putty / cygwin / windows 10 para linux)

Question

Eu tenho um servidor Linux executando o openssh. Eu posso me conectar a ele tanto da LAN local quanto remotamente. No entanto, existe um cliente (um laptop do Windows 10) que só pode se conectar a ele localmente. Quando tento conectar-me remotamente, a autenticação é aceita, mas o cliente ssh no laptop trava e deve ser eliminado com o Process Explorer. Eu pensei que o problema poderia ser:

1. Firewall do Windows - Não. Desliguei, peguei o mesmo comportamento.
2. cliente ssh (cygwin) - Não. Tem o mesmo comportamento com putty.
3. Windows 10 - Não. Eu posso conectar com sucesso remotamente de outra máquina Win10.

Eu tentei uma nova instalação do cygwin & putty.

Eu tentei executar o ssh com várias opções -v e comparar a saída com a outra máquina Win10 que é capaz de se conectar. A saída foi idêntica, até um ponto:

Authenticated to <<IP REMOVED>>.
debug2: fd 5 setting O_NONBLOCK
debug2: fd 6 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting [email protected]
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 91
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768

>>>  "bad" machine hangs here

debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Welcome to Linux Mint 17.3 Rosa (GNU/Linux 3.19.0-32-generic x86_64)

Welcome to Linux Mint

Em raras ocasiões, ele ficou ainda mais - uma ou duas vezes até a mensagem de boas-vindas -, mas a conexão nunca responde à digitação.

Eu tentei executar sshd-d manualmente no servidor e comparar a saída entre uma sessão remota "ruim" e uma "boa" de outro cliente. A saída é idêntica.

Para resumir: não parece ser o Firewall do Windows ou o software cliente ou o Win10, nem o encaminhamento de porta para o servidor, nem o DNS, nem o próprio servidor. O problema é apenas esta máquina cliente, e apenas quando se conecta de fora da LAN local. Está autenticando com sucesso. E a máquina cliente está executando o mesmo cliente OS / ssh que outra máquina que não tem o problema, e também não vejo nada nos logs que a distingue.

EDIT: devo mencionar também, a conexão ssh com outros servidores remotos funciona bem em todas as máquinas. Parece ser apenas este par servidor / cliente, e somente quando se conecta remotamente.

UPDATE: Veja meus comentários imediatamente abaixo para mais informações - o problema parece ser específico da rede local.

Quais etapas adicionais eu posso tomar para depurá-lo?

    

Answer 1

Parece-me que, no ponto em que é interrompido, os pacotes TCP do servidor param de chegar ao cliente. A razão que eu acho que isso é porque às vezes trava em pontos diferentes, e porque o problema varia alterando a configuração da rede. Por exemplo, pode haver alguma interação indesejada entre o encaminhamento de portas, NAT e / ou firewalls. Mas a questão é como diagnosticar porque isso está acontecendo em um cliente, mas não em outro. Duas abordagens que posso pensar:

• Você pode tentar o monitoramento de pacotes no servidor e no cliente e em pontos ao longo a rota para verificar se os pacotes estão realmente se perdendo e em que ponto.

• Você pode tentar encontrar um relacionamento entre as configurações de rede e a existência ou não do problema em clientes diferentes. Troque todas ou algumas configurações de rede e endereços IP entre um cliente em funcionamento e um não funcional para ver se ele resolve o problema.