web-dev-qa-db-de.com

Wie wurde die Anforderung auf dem Kanal nicht behoben?

wenn ich mich so mit meinem Server verbinden möchte

ssh -a [email protected] -p 22

es gibt mir zwei Fehlermeldungen:

PTY allocation request failed on channel 0
Shell request failed on channel 0

wenn ich den Parameter -T verwende, verschwindet die erste Fehlermeldung . Wie kann ich jedoch die zweite beheben? Zu anderen Servern kann ich mich problemlos verbinden.

ich bin unter MAC OS 10.9 Der Parameter -v zeigt mir diese Debug-Ausgabe:

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

nachdem ich das Passwort eingegeben habe, bekomme ich dieses

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
51
user1895268

PTY-Zuordnungsanforderung auf Kanal 0 fehlgeschlagen

Es gibt ein Limit von 256 Pseudo-Terminals in einem System. Vielleicht haben Sie eine Anwendung, die Pseudo-Terminals durchsickert. Benutzen

lsof /dev/pts/*

um zu sehen, welche Prozesse offene Pseudo-Terminals haben

Shell-Anforderung auf Kanal 0 fehlgeschlagen

Ich habe diesen Fehler erhalten (ohne PTY-Zuordnungsfehler). Es stellt sich heraus, dass eine meiner Anwendungen (QtCreator 3.0.?) Zombie-Prozesse durchläuft. Andere Benutzer waren in der Lage, sich anzumelden, sodass ich möglicherweise meine Pro-User-Prozessquote (falls vorhanden) erreicht habe. Ich habe auf QtCreator 3.3 aktualisiert. So weit, ist es gut.

18
vharron

unmount und Mount /dev/pts hat bei mir funktioniert

umount /dev/pts

mount devpts /dev/pts -t devpts

Referenz: http://www.iitk.ac.in/LDP/LDP/lfs/5.0/html/chapter06/proc.html

13
rajagopalx

Ich hatte genau den gleichen Fehler beim Versuch, eine Verbindung mit SSH zu meinem Server herzustellen. Wie ich sehen kann, verwenden Sie einen von Hetzner bereitgestellten Server, der eine Verbindung zu Port 22 herstellt:

debug1: Verbindung zu xxx.your-server.de [188.40.3.15] Port 22.

Das offizielle Wiki/die Dokumentation von Hetzner sagt:

Protokoll zur verschlüsselten Ferndiagnose für Server/Computer (Konsolen). Der zu verwendende SSH-Port ist 222.

Sie müssen also über Port 222 eine Verbindung herstellen:

ssh -p 222 [email protected]
5
tecmec

Fügen Sie diese Zeilen einfach Ihrem /etc/mtab und /etc/fstab hinzu und starten Sie das System neu.

none    /dev/pts    devpts    defaults    0    0
4
Mansur Ali

Ich habe ein ähnliches Problem mit einem unserer Benutzer gelöst, der nur für die Weiterleitung von ssh-Ports verwendet wurde. Daher muss er keinen Zugriff auf PTY haben. In der Datei .ssh/authorised_keys war dies verboten:

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

Wenn Sie also versucht haben, sich bei diesem Benutzer anzumelden, wird nur eine Nachricht angezeigt

PTY allocation request failed on channel 0

wurde zurückgegeben. Überprüfen Sie daher die Datei authorized_keys Ihres Benutzers.

2
Ondrej Homolka

Es ist eine alte Frage, aber wenn jemand wie ich hierher kommt ...

Dies kann auf ein falsches Datum im Server zurückzuführen sein. Wenn Sie mit einem eingebetteten System arbeiten, kann dies die Ursache sein ... Überprüfen Sie also Ihr Datum:

$ date
1

ein Neustart der Instanz von der AWS-Konsole hat für mich funktioniert. Es gab einen Dienst, der Dateiverbindungen durchsickerte und lsof beim Auffinden half.

1
randhir singh

Ich sehe dies gelegentlich beim Hochfahren einer VM. Unser Automatisierungssystem führt ab sofort Aktualisierungen durch, sodass je nach Zeitplan wichtige Pakete aktualisiert werden können.

Fazit: Dies kann passieren, wenn ssh oder andere verwandte Pakete auf dem Zielcomputer aktualisiert werden.

0
Criggie

Versuche dies:

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

Ich bin auf diesen Fehler gestoßen, als ich meine Git-Bash verwendet habe. Ich konnte dieses Problem lösen, indem ich git for windows neu installierte. Weitere Details in diesem Antwort .

0
user3885927

Ich stand auch vor dem gleichen Problem. Nur ein Neustart meiner Server löste das Problem.

0
Vivek Garg

remounting/dev/pts funktioniert für mich. Sie können dies per Fernzugriff über SSH ausführen, wenn Sie SSH wie folgt auf dem betroffenen Computer ausführen. ssh fordert keine tty an, wenn Befehle wie diese ausgeführt werden. Dadurch können Sie/dev/pts remote remounten

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

0

Shell request failed on channel 0

dies bedeutet, dass Sie nicht über Shell- oder Remote-Befehlszugriff verfügen, Ihre Benutzerrechte auf dem Server für den Shell-Zugriff korrigieren. Wenn Sie nur Tunneling verwenden möchten, verwenden Sie die Optionen -N und -T

0
ewwink

ich habe gerade herausgefunden, was das Problem in meinem Fall war (Anbieter strato): Ich hatte das gleiche Problem mit der Ausgabe "Shell-Anforderung auf Kanal 0 fehlgeschlagen" am Ende.

Ich muss das Master-Passwort mit dem Web-Domain-Namen als Login verwenden. (Auf www.wunschname.de, wobei wunschname Ihre Webadresse ist.)

Ein SSH-Login mit SFTP-Benutzernamen und den dazugehörigen Passwörtern ist erfolglos. (Obwohl scp und sftp mit diesen sftp-Benutzern zusammenarbeiten!)

0
feli_x