Problema extraño de SSH, ssh funciona con -t pero se congela sin él

Cuando entro sshen uno de mis servidores, parece iniciar sesión, pero luego se cuelga antes de darme el prompt ( message debug2: shell request accepted on channel 0 is the last log entry).

Aunque lo extraño es que ssh -t "/bin/bash"funciona cuando sshno.

Lo que he descubierto hasta ahora

• Puedo iniciar sesión bien desde servidores en la misma ubicación geográfica normalmente
• Si yo ssh -t '/bin/bash', puedo iniciar sesión perfectamente desde CUALQUIER ubicación.
• Si lo uso rsync para el servidor, parece funcionar, y luego se bloquea
• Si lo uso rsync desde el servidor, funciona sin problemas

Lo que he intentado

• eliminar o cambiar todas las opciones de inicio de sesión .profile,.bashrc /etc/profile
• Cambiar ssh_config y / o sshd_config uno de un servidor idéntico que funciona bien
• He revisado la ruta
• Hice que un experto en redes examinara tcpdumpen vano (aunque parece haber muchas retransmisiones)

Realmente no puedo pensar en otra cosa

Además de un controlador / firmware de tarjeta de red poco fiable.

Eso puede provenir de un problema en el perfil.
Cuando se conecta con ssh -t /bin/bash el shell no lo hará 'login', no va a la fuente de la /etc/profileni la ~/.profilee ~/.bashrc...

Entonces, después de conectarse, coloque el shell en modo de depuración y luego busque cada archivo para encontrar lo que está bloqueando en su interior:

set -x 
. /etc/profile 
...and so on

EDITAR

Tenga en cuenta que estaba equivocado, el archivo .bashrc se obtendrá de cualquier shell interactivo (por lo que aquí solo importan los archivos profile, profile.d).

Intente hacer la lista de las diferentes fases del proceso de conexión. Algo como esto

1) conexión ssh (config, ...)
2) inicio de sesión (PAM, tty, wtmp, ...)
3) inicio del shell (perfil, acceso al directorio de inicio, ...)

Para verificar el (1), puede iniciar el demonio sshd en modo de depuración. Para eso, debe iniciar otro sshd, escuchando un puerto dedicado (no en el puerto 22, por lo que no es necesario detener el demonio sshd normal).

# /usr/sbin/sshd -p 2222 -ddd 

Ese sshd aceptará solo una conexión y no entrará en segundo plano. Abra otra terminal y conéctese a esa sesión ssh.

# ssh -vvv -p 2222 user@host

Puede comparar los mensajes que recibe con los de otro servidor de la misma marca. Entonces sabrá si el problema está en el lado ssh o no.

(-ddd y -vvv son el nivel máximo de depuración, puede ajustar eso)

Tengo ese enlace , mucho más detallado.

La respuesta a mi problema Resulta que era un problema de red. Eventualmente descubrí que al soltar un poco la MTU de todas las tarjetas de red, el problema desapareció.

Lo más probable es que algo esté mal configurado para esa red, pero ahora puedo demostrarlo y entregárselo al equipo de la red (que me decía que era un problema del servidor).

Sin embargo, tenga en cuenta que este es un último recurso. La peculiaridad que tuve fue que el servidor ssh funcionaba desde la misma subred pero no fuera de ella, y ssh -t '/ bin / bash' funcionaba desde cualquier lugar.

También tenía rsyncs que comenzarían bien, pero en algún momento simplemente se cuelga o se cae la conexión.

Entonces, si está viendo esta respuesta, pruebe las otras anteriores primero, y SOLO si tiene rarezas como la mía, es probable que esto ayude.

Así que gracias por toda la ayuda. Intenté todo, y me enseñó muchas cosas, y me permitió confirmar que no tenía nada que ver con el servidor (que es todo lo que esperaba).

Así que gracias a todos los que ayudaron

Cuando lo haga ssh some_user@some_host /bin/bash, lo que está haciendo es lanzar some_user 's (tal como se define en /etc/passwdel some_host ) y luego ejecutar el comando dado, /bin/bashdesde dentro de esa concha.

Ahora, el shell de some_user (supongamos que también lo bashestá) no se inicia de forma interactiva (en su lugar, ejecuta el comando dado). Por lo tanto, no asigna un pty (un pseudo-terminal ) y esto significa que no hay un pty para que el comando emitido lo use, por lo que comienza de forma no interactiva.

En el ejemplo, /bin/bashse inicia el comando solicitado pero parece bloquearse.

Puede solucionar esto pidiendo sshcrear una pty de todos modos para que haya una disponible para el shell y sus procesos secundarios. Esto es lo que -thace.

    $ ssh -t some_user@some_host bash

También puede solucionar esto forzando el comando para crear una pty. Para bash, haces esto pasando una -idiscusión. La siguiente línea de comando también debería funcionar:

$ ssh some_user@some_host bash -i

Sin embargo, tenga en cuenta que en este último caso, el shell no puede acceder /dev/ttyy esto genera una advertencia:

bash: no job control in this shell

Las razones de esto se explican aquí . Esto puede o no ser un problema dependiendo de lo que planeas hacer en el shell, pero usar ssh -tes probablemente la mejor opción.

(tenga en cuenta que de bashtodos modos puede pasar como comando porque de todos modos debería estar en la ruta del shell predeterminado del usuario)

Tengo el mismo problema cuando utilicé una plataforma de virtualización anidada recientemente.

Funciona después de reducir MTU de 1500 a 1400 en el servidor de origen o de destino.

/sbin/ip link set dev eth0 mtu 1400