ssh terminal pty

ssh - Cómo reparar la solicitud fallida en el canal 0



terminal pty (16)

cuando quiero conectarme a mi servidor así

ssh -a [email protected] -p 22

me da dos mensajes de error:

PTY allocation request failed on channel 0 shell request failed on channel 0

cuando uso el parámetro -T el primer mensaje de error desaparece. ¿Pero cómo arreglar el segundo? No puedo conectarme. A otro servidor me puedo conectar sin ningún problema.

Estoy en MAC OS 10.9 El parámetro -v me muestra esta salida de depuración:

OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011 debug1: Reading configuration data /etc/ssh_config debug1: /etc/ssh_config line 20: Applying options for * debug1: Connecting to xxx.your-server.de [188.40.3.15] port 22. debug1: Connection established. debug1: identity file /Users/xxx/.ssh/id_rsa type -1 debug1: identity file /Users/xxx/.ssh/id_rsa-cert type -1 debug1: identity file /Users/xxx/.ssh/id_dsa type -1 debug1: identity file /Users/xxx/.ssh/id_dsa-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.2 debug1: Remote protocol version 2.0, remote software version mod_sftp/0.9.8 debug1: no match: mod_sftp/0.9.8 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Server host key: RSA 55:f5:ca:ca:01:45:0f:7b:71:0a:1f:ba:9e:25:17:fb debug1: Host ''xxx.your-server.de'' is known and matches the RSA host key. debug1: Found key in /Users/xxx/.ssh/known_hosts:1 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Trying private key: /Users/xxx/.ssh/id_rsa debug1: Trying private key: /Users/xxx/.ssh/id_dsa debug1: Next authentication method: password

después de ingresar la contraseña me sale esto

debug1: Authentication succeeded (password). Authenticated to xxx.your-server.de ([xxx.xxx.3.15]:22). debug1: channel 0: new [client-session] debug1: Entering interactive session. debug1: Sending environment. debug1: Sending env LANG = de_DE.UTF-8 shell request failed on channel 0

La solicitud de asignación de PTY falló en el canal 0

Hay un límite de 256 pseudo terminales en un sistema. Tal vez tenga una aplicación que tenga fugas de pseudo terminales. Utilizar

lsof /dev/pts/*

para ver qué procesos tienen pseudo terminales abiertos

solicitud de shell falló en el canal 0

Estaba recibiendo este error (sin error de asignación PTY). Resulta que una de mis aplicaciones (QtCreator 3.0.?) Estaba perdiendo procesos de Zombie. Otros usuarios pudieron iniciar sesión, por lo que podría haber alcanzado mi cuota de proceso por usuario (si existe). He actualizado a QtCreator 3.3. Hasta aquí todo bien.

De vez en cuando veo esto cuando hago girar una VM. Nuestro sistema de automatización comienza a aplicar actualizaciones, por lo que, dependiendo del momento, puede llegar a una actualización de paquetes críticos.

Resultado: esto puede suceder si se actualizan ssh u otros paquetes relacionados en la máquina de destino.

Encontré este error al usar mi git bash. Pude resolver esto reinstalando git para Windows. Más detalles en esta answer .

Es una vieja pregunta, pero si alguien llega aquí como yo ...

Esto podría ser el resultado de una fecha incorrecta en el servidor. Si está trabajando con un sistema integrado, esta podría ser la causa ... Compruebe su fecha:

$ date

Esto sucedía cuando intentaba usar sudo en ssh -t [email protected] después de agregar la clave pública de mi usuario local a github

Solo una cabeza a la gente feliz de Google como yo

Prueba esto:

vi /etc/security/limits.d/20-nproc.conf * soft nproc 4096 # change to 65535 root soft nproc unlimited

Resolví un problema similar con uno de nuestros usuarios que solo se usaba para el reenvío de puertos ssh, por lo que no necesita tener acceso a PTY y estaba prohibido en el archivo .ssh / Authorizedkeys:

no-pty ssh-rsa AAA...nUB9 someuser

Entonces, cuando intentaste iniciar sesión en este usuario, solo aparece el mensaje

PTY allocation request failed on channel 0

fue devuelto Por lo tanto, verifique el archivo de claves autorizadas de su usuario.

Si una persona se encuentra leyendo este QA mientras está intentando ingresar a un dispositivo NetGear ReadyNAS, asegúrese de que la casilla de verificación "rsync only" no esté marcada en el cuadro de diálogo para el servicio ssh en la interfaz de administración.

Simplemente agregue estas líneas a su /etc/mtab y /etc/fstab , y reinicie el sistema.

none /dev/pts devpts defaults 0 0

También enfrenté el mismo problema. Solo reiniciar mis servidores resolvió el problema.

Tuve exactamente el mismo error al intentar conectarme a través de ssh a mi servidor. Como puedo ver, está utilizando un servidor proporcionado por Hetzner que se conecta a él en el puerto 22:

debug1: Conexión a xxx.your-server.de [188.40.3.15] puerto 22.

La wiki / documentación oficial de Hetzner dice:

Protocolo para diagnósticos remotos encriptados para servidores / computadoras (consolas). El puerto SSH que se utilizará es 222.

Entonces debes conectarte a través del puerto 222:

ssh -p 222 [email protected]

acabo de descubrir cuál era el problema en mi caso (estrato de proveedor): al final tuve el mismo problema con la salida "solicitud de shell falló en el canal 0".

Tengo que usar la contraseña maestra con el nombre del dominio web como inicio de sesión. (En alemán www.wunschname.de, donde wunschname es su dirección web).

Un inicio de sesión ssh con nombres de usuario sftp y las contraseñas correspondientes no tiene éxito. (¡Aunque scp y sftp funcionan con estos usuarios de sftp!)

reiniciar la instancia desde la consola de AWS funcionó para mí. Hubo un servicio que estaba filtrando conexiones de archivos que lsof ayudó a encontrar.

remontar / dev / pts funciona para mí. puede hacerlo de forma remota a través de ssh si ejecuta ssh de esta manera contra la máquina afectada. ssh no solicita un tty cuando ejecuta comandos como este y, por lo tanto, esto le permitirá volver a montar / dev / pts de forma remota

ssh user @ host - ''mount -o remount, rw / dev / pts''

shell request failed on channel 0

significa que no tiene acceso a shell o comandos remotos, arregle su permiso de usuario en el servidor para tener acceso a shell o si solo quiere hacer un túnel use las opciones -N y -T