☰

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

tag-icon • tag-icon networking ssh cygwin putty
ssh para servidor remoto trava, mas funciona localmente (putty/cygwin/windows 10 para linux)

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

  1. Firewall do Windows - Não. Desliguei, tive o mesmo comportamento.
  2. cliente ssh (cygwin) - Não. Obteve o mesmo comportamento com massa.
  3. Windows 10 – Não. Posso conectar-me remotamente com êxito a partir de outra máquina Win10.

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

Tentei executar o ssh com várias opções -v e comparar a saída com a outra máquina Win10 capaz de se conectar. A saída foi idêntica, até certo 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 foi mais longe - uma ou duas vezes até a mensagem de boas-vindas - mas a conexão nunca responde à digitação.

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

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

EDIT: Devo mencionar também que 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 conectado remotamente.

ATUALIZAÇÃO: Veja meus comentários abaixo para obter mais informações - o problema parece ser específico da rede local.

Que outras etapas posso seguir para depurá-lo?

Responder1

Parece-me que, no momento em que ele trava, os pacotes TCP do servidor param de chegar ao cliente. Acho que isso acontece porque às vezes ele trava em pontos diferentes e porque o problema varia de acordo com a alteração da configuração da rede. Por exemplo, pode haver alguma interação indesejada entre encaminhamento de porta, NAT e/ou firewalls. Mas a questão é como diagnosticar por que isso está acontecendo em um cliente e não em outro. Posso pensar em duas abordagens:

  • Você poderia tentarmonitoramento de pacotesno servidor e no cliente e em pontos ao longo da rota para verificar se os pacotes estão realmente sendo perdidos e em que ponto.

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

informação relacionada