2011-05-08 12 views
20

Cuando intento ejecutar un comando en un servidor remoto con ssh, el comando ssh se cuelga después del mensaje de depuración exec request accepted, y eventualmente agota el tiempo de espera.Ejecución de comandos SSH Se bloquea, aunque funciones de shell interactivas finas

El mandato que ha fallado: ssh -v -v <username>@<server> uptime (también intentaron echo hello etc.)

debug1: Authentication succeeded (publickey). 
Authenticated to <server> (<ip>:22). 
debug1: channel 0: new [client-session] 
debug2: channel 0: send open 
debug1: Requesting [email protected] 
debug1: Entering interactive session. 
debug2: callback start 
debug2: client_session2_setup: id 0 
debug2: fd 4 setting TCP_NODELAY 
debug1: Sending environment. 
debug1: Sending env LANG = en_US.UTF-8 
debug2: channel 0: request env confirm 0 
debug1: Sending command: uptime 
debug2: channel 0: request exec confirm 1 
debug2: callback done 
debug2: channel 0: open confirm rwindow 0 rmax 32768 
debug2: channel 0: rcvd adjust 2097152 
debug2: channel_input_status_confirm: type 99 id 0 
debug2: exec request accepted on channel 0 

Y no se cuelga, por tiempo indefinido.

Cuando ssh sin un comando en mi servidor remoto, sin embargo, obtengo un shell interactivo y todo está bien.

Comando exitosa: ssh -v -v <username>@<server>

Salida:

debug1: Authentication succeeded (publickey). 
Authenticated to <server> (<ip>:22). 
debug1: channel 0: new [client-session] 
debug2: channel 0: send open 
debug1: Requesting [email protected] 
debug1: Entering interactive session. 
debug2: callback start 
debug2: client_session2_setup: id 0 
debug2: fd 4 setting TCP_NODELAY 
debug2: channel 0: request pty-req confirm 1 
debug1: Sending environment. 
debug1: Sending env LANG = en_US.UTF-8 
debug2: channel 0: request env confirm 0 
debug2: channel 0: request shell confirm 1 
debug2: callback done 
debug2: channel 0: open confirm rwindow 0 rmax 32768 
debug2: channel_input_status_confirm: type 99 id 0 
debug2: PTY allocation request accepted on channel 0 
debug2: channel 0: rcvd adjust 2097152 
debug2: channel_input_status_confirm: type 99 id 0 
debug2: shell request accepted on channel 0 
Welcome! 
<prompt>% 
... 

¿Alguien una idea de por qué una sesión interactiva tendría éxito, pero no una ejecución de comandos?

Hace meses que me atormenta porque no puedo usar unison para sincronizar mis archivos (solía funcionar). Cualquier ayuda muy apreciada.

+0

No conozco la respuesta a tu pregunta, pero tengo una idea. Tal vez hay una configuración incorrecta en su cliente SSH o en el servidor SSH. Pruebe con un cliente diferente para el mismo servidor, y luego intente con el mismo cliente en un servidor diferente, y veamos cuál funciona. – pts

+0

Algunos problemas similares se han publicado anteriormente en stackoverflow: http://www.google.com/search?q=ssh+command+execution+hangs –

+0

No es un problema de configuración de SSH: falla en diferentes clientes. La configuración del servidor está bloqueada por mí, pero verificada por otros usuarios. Los otros problemas publicados aquí no son exactamente los mismos, los he revisado. –

Respuesta

24

El problema era de hecho mi script de inicio de sesión, aunque no tenía que ver con la necesidad de un terminal (lo había sospechado y probado con las opciones -t y -T). El problema era que mi .bashrc estaba ejecutando un exec (en este caso a zsh - porque nuestro sistema no permite chsh a zsh).

La línea en cuestión:

test -f /usr/bin/zsh && exec /usr/bin/zsh 

Resuelto por primera comprobación de shell interactivo y salir si es así:

[ -z "$PS1" ] && return 
test -f /usr/bin/zsh && exec /usr/bin/zsh 

Así que, esencialmente, porque la cáscara se execing en zsh, ssh estaba esperando esto para terminar, lo que nunca sucedió.

Estoy un poco confundido por qué mi .bashrc se llamaba en absoluto - Pensé que esto era solo para shells interactivos, pero el propósito exacto y el orden de los varios scripts de inicio es algo que no creo que pueda aprender .

Espero que esto pueda ser útil para otros que tienen algún tipo de exec en sus scripts de inicio.

BTW - las otras dos respuestas estaban en el camino correcto, así que no estaba seguro de si debería 'responder' o simplemente comentar sus respuestas. Si responder mi propia pregunta es moralmente incorrecto en stackoverflow, avísame y haré penitencia. Gracias a los otros respondedores.

+1

.bashrc = invoca cada vez que se invoca el shell y se adjunta a un terminal. .bash_profile solo se invoca al iniciar sesión. La distinción es vaga, pero se puede verificar fácilmente con echo 'echo estoy conectado en'> ~/.bash_profile y ejecutando un comando usando ssh. De esta forma, puede ver si la ejecución directa de comandos a través de ssh hace o no que el shell sea un shell de inicio de sesión. – Mel

+0

Me encontré con el mismo problema utilizando oh-my-zsh, tuve que insertar '[-z" $ PS1 "] && return' justo antes de' source $ ZSH/oh-my-zsh.sh' para evitar SSH colgado cuando se usa otro host como proxy –

2

Compruebe si hay comandos en los archivos de inicio de su shell (supongo que ~/.cshrc en su aviso, en una sesión no interactiva, ~/.login) que requieren un terminal por algún motivo.

4

Es probable que su problema resida en el inicio de su shell o en los scripts del logout. Sin saber lo que hay allí, es difícil adivinar el problema real.

2

Recientemente encontré un problema con los mismos síntomas, pero determiné que el problema era no un problema en mis scripts de inicio de sesión. Por el contrario, mi archivo local .ssh/config se configuró con RequestTTY force para el host que estaba intentando copiar.

0

Tuve este problema en el servidor fedora 22, después de la resolución de otros problemas nuevos.

ssh -t ziimp/bin/true estaba bien pero no ssh ziimp/bin/true y todos mis git + ssh y scp estaban bloqueados.

La solución que encontré estaba en el archivo authorized_keys. Tuve que eliminar el prefijo command = "/ usr/bin/bash" de mis claves de confianza ...

Cuestiones relacionadas