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

11

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

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

blauwblaatje
la source
5
Pouvez-vous utiliser ssh user@host "/bin/bash -i"pour vous connecter?
Tim
hmm .. ouais, ça marche ...
blauwblaatje
1
J'ai vu un cas où les /dev/pt*appareils devaient être retirés et rajoutés manuellement car ils étaient corrompus. Et dans ce cas, l'utilisation de la solution de contournement que j'ai énumérée ci-dessus a également fonctionné.
Tim
@Tim J'ai le même problème. Je peux également me connecter avec ssh user@host "/bin/bash -i. Pourriez-vous être plus précis sur les commandes que je dois exécuter pour résoudre ce problème? Comment restaurer /dev/pt*? Merci.
Erwin Rooijakkers du
4
@ run user2609980 mount, l'une des lignes sorties doit être / dev / pts, notez les options. Démontez umount /dev/ptset remontez en mount -t devpts -o OPTIONS devpts /dev/ptsremplaçant OPTIONS par les options que vous avez observées avant le démontage.
Tim

Réponses:

10

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

blauwblaatje
la source
C'est très étrange. Une idée pourquoi c'est ainsi? Est-ce un bug de pilote de périphérique ou autre chose? At-il été corrigé? etc ...
not2qubit
Aucune idée. Et je ne l'ai pas revu.
blauwblaatje
1
@blauwblaatje J'ai le même problème. Je peux également me connecter avec ssh user@host "/bin/bash -i. Pourriez-vous être plus précis sur les commandes que je dois exécuter pour résoudre ce problème? Merci.
Erwin Rooijakkers du
Pour autant que je me souvienne, je n'ai fait que: umount / dev / pts && mount / dev / pts
blauwblaatje
J'ai juste eu le problème et je devais le faire mkdir /dev/ptsavant que ça marche. Sinon, cela a résolu le problème pour moi.
Angelo Fuchs
1

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.

Pérez P. Javier E.
la source
1

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 )

Uwe Geuder
la source
0

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
Couteau Vidar
la source
2
Pourquoi pensez-vous que le problème pourrait être lié aux variables d'environnement LANGet LC_*?
Adrian Heine
Je me demande ce que j'ai changé avant que cela ne se produise. J'ai en fait changé certaines de ces variables! Voyons voir si ça marche aussi pour moi.
Erwin Rooijakkers du
0

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.

MiKu
la source