Por que não posso usar ssh em um servidor da rede do meu escritório?

Question

Tenho problemas para conectar via SSH a um servidor sempre que estou no escritório. Eu recebo a solicitação da minha senha e depois disso há uma longa espera que sempre termina em

Write failed: Broken pipe

Isto é apenas para conectar via SSH. Eu uso svn para enviar arquivos para um repositório hospedado no mesmo servidor e não há problemas.

Além disso, isso só acontece em nosso escritório. Quando vou à universidade ou sempre que estou em casa ou no café, posso me conectar perfeitamente. Não há firewalls em nosso escritório. É apenas um roteador sem fio básico conectado a uma configuração de modem. É a mesma configuração que tenho em casa e acho que a mesma configuração no café.

Quais são as causas de um cano quebrado e por que esse fenômeno só acontece quando eu tento conectar via SSH e não quando eu trabalho com o svn no mesmo servidor?

Atualizado : alguns logs de depuração após a autenticação:

debug3: packet_send2: adding 48 (len 64 padlen 16 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug3: Ignored env ORBIT_SOCKETDIR
debug3: Ignored env SSH_AGENT_PID
debug3: Ignored env TERM
debug3: Ignored env SHELL
debug3: Ignored env XDG_SESSION_COOKIE
debug3: Ignored env WINDOWID
debug3: Ignored env GNOME_KEYRING_CONTROL
debug3: Ignored env GTK_MODULES
debug3: Ignored env USER
debug3: Ignored env LS_COLORS
debug3: Ignored env LIBGL_DRIVERS_PATH
debug3: Ignored env SSH_AUTH_SOCK
debug3: Ignored env DEFAULTS_PATH
debug3: Ignored env SESSION_MANAGER
debug3: Ignored env USERNAME
debug3: Ignored env XDG_CONFIG_DIRS
debug3: Ignored env DESKTOP_SESSION
debug3: Ignored env LIBGL_ALWAYS_INDIRECT
debug3: Ignored env PATH
debug3: Ignored env PWD
debug3: Ignored env GDM_KEYBOARD_LAYOUT
debug1: Sending env LANG = en_PH.utf8
debug2: channel 0: request env confirm 0
debug3: Ignored env GNOME_KEYRING_PID
debug3: Ignored env MANDATORY_PATH
debug3: Ignored env GDM_LANG
debug3: Ignored env GDMSESSION
debug3: Ignored env SHLVL
debug3: Ignored env HOME
debug3: Ignored env GNOME_DESKTOP_SESSION_ID
debug3: Ignored env LOGNAME
debug3: Ignored env XDG_DATA_DIRS
debug3: Ignored env DBUS_SESSION_BUS_ADDRESS
debug3: Ignored env LESSOPEN
debug3: Ignored env WINDOWPATH
debug3: Ignored env DISPLAY
debug3: Ignored env LESSCLOSE
debug3: Ignored env XAUTHORITY
debug3: Ignored env COLORTERM
debug3: Ignored env OLDPWD
debug3: Ignored env _
debug2: channel 0: request shell confirm 1
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768

UPDATE 2011-14-07: Agora posso me conectar ao servidor via SSH. Eu não fiz nada, mas isso é porque não há ninguém no escritório além de mim! Dito isso, é possível que tenha algo a ver com o número de sessões que um servidor SSH pode manipular?

ATUALIZAÇÃO 2011-14-07: Eu tento fazer o login via SSH através de Putty em outra máquina rodando windows junto com a minha atual sessão SSH no Ubuntu e agora parece que minha sessão SSH no Ubuntu foi descartada . Não consigo digitar no terminal. Putty é o culpado agora?

    

Answer 1

Isso parece algo estranho acontecendo no roteador sem fio. O fato de que duas sessões de SSH de diferentes máquinas parecem interferir é muito provavelmente relevante.

Entre as coisas que um roteador wifi faz, e que podem afetar uma conexão SSH, estão MTU / windowing (o que deve fazer com que você tenha uma conexão suspensa) e o TCP keepalive caindo (o que pode levar a uma falha pipe "erro".

Então eu tentei desativar a opção TCP keepalive do SSH:

ssh -C -o TCPKeepAlive=no yourserver

e veja se isso muda alguma coisa. Eu também tentaria, se possível, conectar o computador ao roteador usando um cabo ou temporariamente usando um roteador diferente.

Observe um problema semelhante aqui onde o Ipwaqas usa os termos,

This is very old problem for me; Every time I reinstall my system I have to add the line below to my /etc/ssh/ssh_config to avoid “Write failed: Broken pipe” issue.

ServerAliveInterval 120
OR
ClientAliveInterval 15

Existem algumas opções engraçadas em roteadores WiFi que lidam com programas clientes, mas eles são normalmente jogos e afins; Eu não esperaria que houvesse algo envolvendo SSH. Mas só por precaução, verifique isso também.

    

Answer 2

Com base nas informações adicionais, sugiro as seguintes etapas de diagnóstico:

Quando eu tento isso (com sucesso), uma das próximas entradas é uma alocação de PTY. Eu sugiro tentar o mesmo comando ssh com -t e -T, para ver se isso afeta se funciona ou não.

Outras coisas para analisar incluem: * Verificando se o problema segue o cliente ou o servidor. * Veja se você pode executar comandos remotos (por exemplo, ssh some.host echo "connected") * Veja se você pode usar scp.

Estes devem ajudar a diminuir o problema, mesmo que não o resolvam.

    

Answer 3

Você já viu isso ...

link