linux - protocolo - ssh windows
La ejecución del comando SSH se bloquea, aunque las funciones de shell interactivas están bien (6)
Cuando intento ejecutar un comando en un servidor remoto con ssh, el comando ssh se bloquea después de que la exec request accepted mensaje de depuración y, finalmente, se agote.
El comando que falla: ssh -v -v <username>@<server> uptime (también probé 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 ahí cuelga, indefinidamente.
Cuando ssh sin un comando en mi servidor remoto, sin embargo, obtengo un shell interactivo y todo está bien.
Comando exitoso: 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 tiene una idea de por qué una sesión interactiva sería exitosa pero una ejecución de comando no?
Me ha estado persiguiendo durante meses porque ya no puedo usar unison para sincronizar mis archivos (solía funcionar). Cualquier ayuda muy apreciada.
Arreglamos esto agregando -n (para redireccionar std desde / dev / null) y -t (forzar la asignación de pseudo-tty)
Ejemplo:
ssh -t -n user@host command
El problema era, de hecho, mi script de inicio de sesión, aunque no tenía que ver con requerir un terminal (sospeché eso y lo probé con las opciones -t y -T ). El problema fue que mi .bashrc estaba ejecutando un exec (en este caso para zsh , porque nuestro sistema no permite que chsh to zsh ).
La línea ofensiva:
test -f /usr/bin/zsh && exec /usr/bin/zsh
Resuelto al verificar primero la shell interactiva y salir si es así:
[ -z "$PS1" ] && return
test -f /usr/bin/zsh && exec /usr/bin/zsh
Básicamente, debido a que la shell estaba ejecutando en zsh , ssh estaba esperando que esto terminara, lo que nunca sucedió.
Estoy un poco confundido de por qué se llamaba a mi .bashrc . Pensé que esto era solo para shells interactivos, pero el propósito y el orden exacto de los distintos guiones de inicio es algo que creo que nunca aprenderé.
Espero que esto pueda ser útil para otros que tienen algún tipo de exec en sus scripts de inicio.
Por cierto, las otras dos respuestas estaban en el camino correcto, así que no estaba segura de si debía "responder" o simplemente comentar sus respuestas. Si responder mi propia pregunta es moralmente incorrecto en el flujo de pila, avíseme y haré penitencia. Gracias a los otros respondedores.
Recientemente encontré un problema con los mismos síntomas, pero determiné que el problema no era un problema en mis scripts de inicio de sesión. Más bien, mi archivo .ssh/config local se configuró con RequestTTY force para el host en el que estaba intentando copiar.
Su problema probablemente se encuentra en el inicio de su shell o en los scripts de cierre de sesión del shell. Sin saber qué hay allí, es difícil adivinar el problema real.
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 de comando = "/ usr / bin / bash" de mis claves de confianza ...
Verifique los comandos en los archivos de inicio de su shell (supongo que ~/.cshrc desde su solicitud; en una sesión no interactiva, ~/.login no debería importar) que requieren un terminal por alguna razón.