¿Por qué no puedo ingresar a un servidor desde la red de mi oficina?

Tengo problemas para conectarme a través de SSH a un servidor cada vez que estoy en la oficina. Llego a que se me solicite mi contraseña y luego hay una larga espera que siempre termina en un

Write failed: Broken pipe

Esto es solo para conectarse a través de SSH. Uso svn para enviar archivos a un repositorio alojado en el mismo servidor y no hay problemas.

Además, esto solo sucede en nuestra oficina. Cuando voy a la universidad o cuando estoy en casa o en la cafetería, puedo conectarme sin problemas. No hay firewalls en nuestra oficina. Es solo un enrutador inalámbrico básico conectado a una configuración de módem. Es la misma configuración que tengo en casa y supongo que la misma configuración en la cafetería.

¿Cuáles son las causas de una tubería rota y por qué este fenómeno solo ocurre cuando intento conectarme a través de SSH y no cuando trabajo con svn en el mismo servidor?

Actualizado : algunos registros de depuración después de la autenticación:

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

ACTUALIZACIÓN 2011-14-07: Ahora puedo conectarme al servidor a través de SSH. No hice nada, ¡pero eso es porque no hay nadie en la oficina que no sea yo! Dicho esto, ¿es posible que tenga algo que ver con la cantidad de sesiones que puede manejar un servidor SSH?

ACTUALIZACIÓN 2011-14-07: Intento iniciar sesión a través de SSH a través de Putty en otra máquina que ejecuta Windows junto con mi sesión SSH actual en Ubuntu y ahora parece que mi sesión SSH en Ubuntu se ha eliminado. No puedo escribir en la terminal. ¿Putty es el culpable ahora?

Esto parece algo extraño en el enrutador inalámbrico. El hecho de que dos sesiones SSH de diferentes máquinas parecen interferir es muy probablemente relevante.

Entre las cosas que se sabe que hace un enrutador wifi, y que pueden afectar una conexión SSH, se encuentran MTU / ventanas (que deberían tener una conexión bloqueada) y caída de TCP keepalive (que podría conducir a un error de "tubería rota" )

Así que intentaría deshabilitar la opción TCP keepalive de SSH:

ssh -C -o TCPKeepAlive=no yourserver

y ver si esto cambia algo. También intentaría, si es posible, conectar la computadora al enrutador usando un cable, o temporalmente usando un enrutador diferente.

Tenga en cuenta un problema similar aquí donde usa estados Ipwaqas,

Este es un problema muy viejo para mí; Cada vez que reinstalo mi sistema, tengo que agregar la siguiente línea a mi / etc / ssh / ssh_config para evitar el problema "Error de escritura: tubería rota".

ServerAliveInterval 120
OR
ClientAliveInterval 15

Hay algunas opciones divertidas en los enrutadores WiFi que se ocupan de los programas del cliente, pero normalmente son juegos y cosas por el estilo; No esperaría que hubiera algo relacionado con SSH. Pero por si acaso, échale un vistazo también.

Según la información adicional, sugiero los siguientes pasos de diagnóstico:

Cuando intento esto (con éxito), una de las siguientes entradas es una asignación PTY. Sugiero probar el mismo comando ssh con -t y -T, para ver si eso afecta si funciona o no.

Otras cosas a considerar incluyen: * Ver si el problema sigue al cliente o al servidor. * Vea si puede ejecutar comandos remotos (por ejemplo, ssh some.host echo "conectado") * Vea si puede usar scp.

Esto debería ayudar a reducir el problema, incluso si no lo resuelven.

¿Has investigado esto ...

https://bbs.archlinux.org/viewtopic.php?id=97003