SSH falla: la solicitud de asignación PTY falló en el canal 0

11

Así que busqué en Google el error y verifiqué la falla del servidor, pero las soluciones no encajaban. La mayoría de los resultados fueron problemas con / dev / pts, pero eso está montado. Otros resultados son errores con git, pero no hay git en la máquina.

Mi cuenta no está bloqueada, todavía puedo iniciar sesión en la consola. Otros usuarios también tienen este problema, así que no creo que tenga algo que ver con algo que está en mi .ssh /

Recibo esta respuesta con ssh -vv:

<snip>
debug1: Next authentication method: password
rogier@server's password: 
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
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: 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: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 100 id 0
PTY allocation request failed 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

Después de esto, la sesión se congela. ¿Alguien tiene alguna idea de lo que está pasando?

ssh debian blauwblaatje
fuente
55
¿Puedes usar ssh user@host "/bin/bash -i"para iniciar sesión?
Tim
hmm .. sí, eso funciona ...
blauwblaatje
1
He visto un caso en el /dev/pt*que los dispositivos debían eliminarse y volver a agregarse manualmente porque se corrompieron. Y en ese caso, usar la solución que enumeré anteriormente también funcionó.
Tim
@Tim tengo el mismo problema. También puedo iniciar sesión con ssh user@host "/bin/bash -i. ¿Podría ser más específico sobre qué comandos tengo que ejecutar para solucionar esto? ¿Cómo restauro /dev/pt*? Gracias.
Erwin Rooijakkers
44
@ user2609980 ejecutar mount, una de las líneas de salida debe ser / dev / pts, tome nota de las opciones. Desmonte umount /dev/ptsy vuelva a montar con mount -t devpts -o OPTIONS devpts /dev/ptsOPCIONES de reemplazo con las opciones que observó antes de desmontar.
Tim

Respuestas:

10

Ok, gracias a Tim. umounting / dev / pts y luego mount / dev / pts hicieron el truco.

blauwblaatje
fuente
Esto es muy extraño. ¿Alguna idea de por qué esto es así? ¿Es esto un error del controlador del dispositivo o algo más? ¿Ha sido arreglado? etc ...
not2qubit
Ni idea. Y no lo he vuelto a ver.
blauwblaatje 01 de
1
@blauwblaatje Tengo el mismo problema. También puedo iniciar sesión con ssh user@host "/bin/bash -i. ¿Podría ser más específico sobre qué comandos tengo que ejecutar para solucionar esto? Gracias.
Erwin Rooijakkers
Hasta donde puedo recordar, solo hice: umount / dev / pts && mount / dev / pts
blauwblaatje
Acabo de tener el problema y tuve que hacerlo mkdir /dev/ptsantes de que funcionara. De lo contrario, esto resolvió el problema para mí.
Angelo Fuchs
1

déjame contarte toda mi experiencia, trato de conectarme desde linux a windows a través de ssh, tuve servidores con openssh y otros con freessh . Cuando el servidor tiene openssh funciona bien, pero desde ahora comienza a presentar un mensaje de "solicitud de shell fallida en el canal 0" cuando freessh está ejecutando el servicio (vino de un día para otro, solía funcionar mejor que openssh)

Una prueba realizada por mí fue intentar establecer la conexión de otro usuario, ya que veo que funciona bien, realizo una copia de seguridad de mi ~ / .ssh (el usuario que presenta el problema), y después de eso funciona bien.

Creo que el archivo involucrado era conocido_hosts, las permanentes se ven bien así como el contenido, pero así fue como lo solucioné.

Pérez P. Javier E.
fuente
1

El error solo significa que la apertura del pseudo terminal falló. Lo más probable es que no tenga nada que ver con ssh. Para depurarlo en el lado del servidor ssh, use una demostración PTY muy simple como mypty en http://rachid.koucha.free.fr/tech_corner/pty_pdip.html para ver si se puede asignar algún PTY. Si no, usa strace para investigar dónde falla. (Para mí, faltaba un enlace simbólico / dev / ptmx en un contenedor como se explica en https://www.kernel.org/doc/Documentation/filesystems/devpts.txt )

Uwe Geuder
fuente
0

Podría depender de su LANG y su configuración de LC, pero esto funciona para mí:

unset LANG        2>/dev/null
unset LC_MONETARY 2>/dev/null
unset LC_NUMERIC  2>/dev/null
unset LC_MESSAGES 2>/dev/null
unset LC_COLLATE  2>/dev/null
unset LC_CTYPE    2>/dev/null
ssh -l username hostname
Cuchillo Vidar
fuente
2
¿Por qué cree que el problema podría estar relacionado con las LANGy LC_*variables de entorno?
Adrian Heine
Me pregunto qué cambié antes de que esto comenzara a suceder. ¡De hecho, cambié algunas de estas variables! Veamos si también funciona para mí.
Erwin Rooijakkers
0

En mi caso, me estaba conectando a un host de Windows (ejecutando cygwin y otros softwares relacionados) desde una caja de Linux.

Extrañamente, los intentos de conectarse al servidor de Windows funcionaron pero fallaron al asignar un terminal interactivo. Verifique los ssh -vvregistros a continuación.

...
Authentication succeeded
...
Entering interactive session
Requesting authentication agent forwarding.
Sending environment.
Sending env LANG = en_US.UTF-8
PTY allocation request failed on channel 4
...

Mi colega descubrió que era debido a muchos procesos abiertos en el servidor de Windows que usaba las mismas credenciales de inicio de sesión que el mío y realizaba una operación por lotes automatizada.

Matarlo temporalmente, hizo el truco y permitió mi conexión ssh con éxito.

Lo más probable, windows + cygwin, tenía un límite máximo en ese sentido. Queda trabajo por desasignar recursos correctamente cuando esos procesos se terminen de ejecutar.

MiKu
fuente