Comment résoudre la demande a échoué sur le canal
quand je veux me connecter à mon serveur comme ça
ssh -a [email protected] -p 22
cela me donne deux messages d'erreur:
PTY allocation request failed on channel 0
Shell request failed on channel 0
lorsque j'utilise le paramètre -T, le premier message d'erreur disparaît . Mais comment résoudre le second? Je ne peux pas me connecter. À un autre serveur, je peux me connecter sans aucun problème.
je suis sous MAC OS 10.9 Le paramètre -v me montre cette sortie de débogage:
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
après avoir entré le mot de passe, je reçois ce
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 demande d'allocation PTY a échoué sur le canal 0
Il existe une limite de 256 pseudo-terminaux sur un système. Vous avez peut-être une application qui fuit des pseudo-terminaux. Utilisation
lsof /dev/pts/*
pour voir quels processus ont des pseudo-terminaux ouverts
La requête shell a échoué sur le canal 0
Je recevais cette erreur (sans erreur d'allocation PTY). Il s'avère que l'une de mes applications (QtCreator 3.0.?) Présentait une fuite de processus Zombie. D'autres utilisateurs ont pu se connecter et j'ai peut-être atteint mon quota de processus par utilisateur (le cas échéant). J'ai mis à jour QtCreator 3.3. Jusqu'ici tout va bien.
démonter et monter /dev/pts travaillé pour moi
umount /dev/pts
mount devpts /dev/pts -t devpts
Référence: http://www.iitk.ac.in/LDP/LDP/lfs/5.0/html/chapter06/proc.html
J'ai eu exactement la même erreur en essayant de me connecter via ssh à mon serveur. Comme je peux le voir, vous utilisez un serveur fourni par Hetzner qui s'y connecte sur le port 22:
debug1: Connexion au port 22 de xxx.your-server.de [188.40.3.15].
Le wiki officiel/documentation de Hetzner dit:
Protocole de diagnostic à distance crypté pour serveurs/ordinateurs (consoles). Le port SSH à utiliser est 222.
Vous devez donc vous connecter via le port 222:
ssh -p 222 [email protected]
Ajoutez simplement ces lignes à vos /etc/mtab et /etc/fstab et redémarrez le système.
none /dev/pts devpts defaults 0 0
J'ai résolu un problème similaire avec l'un de nos utilisateurs qui était utilisé uniquement pour le transfert de port ssh. Il n'a donc pas besoin d'avoir accès à PTY et cela était interdit dans le fichier .ssh/allowed_keys:
no-pty ssh-rsa AAA...nUB9 someuser
Ainsi, lorsque vous essayez de vous connecter à cet utilisateur, seul le message
PTY allocation request failed on channel 0
a été retourné. Vérifiez donc le fichier registered_keys de votre utilisateur.
C'est une vieille question, mais si quelqu'un arrive comme moi ...
Cela peut être dû à une date erronée sur le serveur. Si vous travaillez avec un système intégré, cela peut en être la cause ... Vérifiez donc votre date:
$ date
le redémarrage de l'instance à partir de la console AWS a fonctionné pour moi. Il y avait un service qui fuyait les connexions de fichiers que lsof avait aidé à trouver.
Je vois parfois cela lorsque je tourne une machine virtuelle. Notre système d'automatisation commence à appliquer les mises à jour. Par conséquent, en fonction du moment, une mise à jour des packages critiques peut être mise à jour.
Upshot - cela peut arriver si ssh ou d'autres packages associés sont mis à jour sur la machine de destination.
Essaye ça:
vi /etc/security/limits.d/20-nproc.conf
* soft nproc 4096 # change to 65535
root soft nproc unlimited
J'ai rencontré cette erreur en utilisant mon git bash. J'ai pu résoudre ce problème en réinstallant git pour Windows. Plus de détails dans ce réponse .
J'ai également fait face au même problème. Le simple redémarrage de mes serveurs a résolu le problème.
remonter/dev/pts fonctionne pour moi. vous pouvez le faire à distance via ssh si vous exécutez ssh de la sorte sur la machine affectée. ssh ne demande pas de tty lors de l'exécution de commandes de ce type, ce qui vous permettra de remonter à distance/dev/pts
ssh utilisateur @ hôte - 'mount -o remount, rw/dev/pts'
Shell request failed on channel 0
signifie que vous n'avez pas accès aux commandes Shell ou à distance, corrigez l'autorisation de l'utilisateur sur le serveur pour avoir un accès Shell ou si vous souhaitez simplement utiliser un tunnel, utilisez les options -N et -T
je viens de découvrir quel était le problème dans mon cas (fournisseur strato): J'ai eu le même problème avec la sortie "La requête du shell a échoué sur le canal 0" à la fin.
Je dois utiliser le mot de passe principal avec le nom de domaine Web comme identifiant. (En allemand www.wunschname.de, où wunschname est votre adresse Web.)
Une connexion SSH avec les noms d'utilisateur sftp et les mots de passe correspondants est sans succès. (Bien que scp et sftp fonctionne avec ces utilisateurs de sftp!)