SSH échoue: la demande d'allocation PTY a échoué sur le canal 0

J'ai donc recherché l'erreur sur Google et vérifié la défaillance du serveur, mais les solutions ne convenaient pas. La plupart des résultats étaient des problèmes avec / dev / pts, mais cela est monté. D'autres résultats sont des erreurs avec git, mais il n'y a pas de git sur la machine.

Mon compte n'est pas bloqué, je peux toujours me connecter sur la console. D'autres utilisateurs ont également ce problème, donc je ne pense pas que cela ait quelque chose à voir avec quelque chose qui est dans mon .ssh /

J'obtiens cette réponse avec 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 no-more-sessions@openssh.com
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

Après cela, la session se fige. Quelqu'un a-t-il une idée de ce qui se passe?

D'accord, merci à Tim. umounting / dev / pts puis mount / dev / pts ont fait l'affaire.

laissez-moi vous raconter toute mon expérience, j'essaie de me connecter de linux à windows via ssh, j'avais des serveurs avec openssh et d'autres avec freessh . Lorsque le serveur a ouvert, il fonctionne correctement, mais depuis un certain temps, il commence à présenter un message "la demande du shell a échoué sur le canal 0" lorsque freessh est le service en cours d'exécution (il est venu d'un jour à l'autre, il fonctionne mieux que openssh)

Un test que j'ai fait était d'essayer de créer une connexion avec un autre utilisateur, car je vois que cela fonctionne bien, je sauvegarde mon ~ / .ssh (l'utilisateur qui présente le problème), et après cela fonctionne correctement.

Je pense que le fichier impliqué était connu_hôtes, la perms semble bien ainsi que le contenu, mais c'est comme ça que je le corrige.

L'erreur signifie simplement que l'ouverture du pseudo-terminal a échoué. Très probablement, cela n'a rien à voir avec ssh. Pour le déboguer côté serveur ssh, utilisez une démo PTY très simple comme mypty dans http://rachid.koucha.free.fr/tech_corner/pty_pdip.html pour voir si un PTY peut être alloué. Sinon, utilisez strace pour rechercher où il échoue. (Pour moi, il s'agissait d'un lien symbolique / dev / ptmx manquant dans un conteneur, comme expliqué dans https://www.kernel.org/doc/Documentation/filesystems/devpts.txt )

Cela pourrait dépendre de vous LANG et de vos paramètres LC, mais cela fonctionne pour moi:

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

Dans mon cas, je me connectais à un hôte Windows (exécutant cygwin et d'autres logiciels associés) à partir d'une boîte Linux.

Étrangement, les tentatives de connexion au serveur Windows ont fonctionné mais ont échoué lors de l'allocation du terminal interactif. Consultez les ssh -vvjournaux ci-dessous.

...
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
...

Mon collègue a compris que c'était à cause de nombreux processus ouverts sur le serveur Windows qui utilisait les mêmes informations de connexion que le mien et effectuait une opération de traitement par lots automatisée.

Le tuer temporairement, a fait l'affaire et a permis à ma connexion ssh de réussir.

Très probablement, windows + cygwin, avait une limite maximale à cet égard. Il reste du travail pour désallouer correctement les ressources lorsque ces processus sont terminés.

En remontant je reçois,

warning: can't open /etc/fstab: No such file or directory

Mais,

mount devpts /dev/pts -t devpts

faire l'affaire

Référence: http://www.iitk.ac.in/LDP/LDP/lfs/5.0/html/chapter06/proc.html