Wanneer ik verbinding wil maken met mijn server als deze
ssh -a [email protected] -p 22
Het geeft me twee foutmeldingen:
PTY allocation request failed on channel 0
shell request failed on channel 0
Wanneer ik de parameter -Thet eerste foutmelding verdwijnt.
Maar hoe de tweede te repareren?
Ik kan geen verbinding maken. Aan andere servers kan ik zonder problemen verbinding maken.
Ik ben op Mac OS 10.9.
De parameter -vtoont me deze foutopsporingen:
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
Nadat ik het wachtwoord heb ingevoerd, krijg ik dit:
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
Antwoord 1, autoriteit 100%
PTY-toewijzingsverzoek mislukt op kanaal 0
Er is een limiet van 256 pseudo-terminals op een systeem. Misschien heb je een applicatie die pseudo-terminals lekt. Gebruik
lsof /dev/pts/*
om te zien welke processen open pseudo-terminals hebben
shell-verzoek mislukt op kanaal 0
Ik kreeg deze foutmelding (zonder PTY-toewijzingsfout). Het blijkt dat een van mijn applicaties (QtCreator 3.0.?) Zombie-processen lekte. Andere gebruikers konden inloggen, dus misschien had ik mijn quotum per proces per gebruiker bereikt (als er zoiets bestaat). Ik heb geüpdatet naar QtCreator 3.3. Tot nu toe zo goed.
Antwoord 2, autoriteit 93%
ontkoppelen en koppelen /dev/ptswerkte voor mij
umount /dev/pts
mount devpts /dev/pts -t devpts
Referentie: http://www. iitk.ac.in/LDP/LDP/lfs/5.0/html/chapter06/proc.html
Antwoord 3, autoriteit 33%
Ik had exact dezelfde fout toen ik via ssh verbinding probeerde te maken met mijn server. Zoals ik kan zien, gebruik je een server van Hetzner die er verbinding mee maakt op poort 22:
debug1: verbinding maken met xxx.your-server.de [188.40.3.15] poort 22.
De officiële wiki/documentatie van Hetznerzegt:
Protocol voor versleutelde diagnose op afstand voor servers/computers (consoles). De te gebruiken SSH-poort is 222.
Je moet dus verbinding maken via poort 222:
ssh -p 222 [email protected]
Antwoord 4, autoriteit 26%
Ik heb een soortgelijk probleem opgelost met een van onze gebruikers die alleen werd gebruikt voor het doorsturen van ssh-poorten, zodat hij geen toegang tot PTY nodig had en het was verboden in het .ssh/authorized_keys-bestand:
no-pty ssh-rsa AAA...nUB9 someuser
Dus toen je probeerde in te loggen bij deze gebruiker, alleen bericht
PTY allocation request failed on channel 0
is geretourneerd. Controleer dus het Authorized_keys-bestand van uw gebruiker.
Antwoord 5, autoriteit 15%
Voeg deze regels gewoon toe aan uw /etc/mtaben /etc/fstaben start het systeem opnieuw op.
none /dev/pts devpts defaults 0 0
Antwoord 6, autoriteit 15%
Probeer dit:
vi /etc/security/limits.d/20-nproc.conf
* soft nproc 4096 # change to 65535
root soft nproc unlimited
Antwoord 7, autoriteit 15%
net ontdekt wat het probleem was in mijn geval (provider strato):
Ik had uiteindelijk hetzelfde probleem met de output “shell request failed on channel 0”.
Ik moet het hoofdwachtwoord met de webdomeinnaam als login gebruiken. (In het Duits
www.wunschname.de, waar wunschname uw webadres is.)
Een ssh-login met sftp-gebruikersnamen en de bijbehorende wachtwoorden is zonder succes. (Hoewel scp en sftp werken met deze sftp-gebruikers!)
Antwoord 8, autoriteit 7%
Het is een oude vraag, maar als iemand hier komt zoals ik…
Dit kan het gevolg zijn van een verkeerde datum op de server. Als je met een embedded systeem werkt, kan dit de oorzaak zijn… Dus check je datum:
$ date
Antwoord 9, autoriteit 4%
het opnieuw opstarten van de instantie vanaf de AWS-console werkte voor mij. Er was een service die bestandsverbindingen lekte die lsofhielp vinden.
Antwoord 10, autoriteit 4%
shell request failed on channel 0
betekent dat je geen toegang hebt tot shell of externe commando’s, stel je gebruikersrechten op de server in om shell-toegang te krijgen of als je gewoon tunneling wilt, gebruik dan -Nen -Topties
Antwoord 11, autoriteit 4%
Ik heb ook met hetzelfde probleem te maken gehad. Door mijn servers opnieuw op te starten, was het probleem opgelost.
Antwoord 12, autoriteit 4%
Dit is wat me heeft geholpen door de verschillende antwoorden die werden gegeven.
- Probeer in te loggen als root, dan kom je er meestal wel uit
- Probeer in te loggen als een andere gebruiker, het is gelukt, het betekent dat het probleem bij een specifiek account zit & het houdt in dat er al enkele processen zijn gestart door het problematische account die bronnen verbruiken die inloggen voorkomen (waarschijnlijk geen processen)
- Verhoog de limiet in /etc/security/limits.d/20-nproc.conf zoals hierboven vermeld door xmduhan
- Probeer opnieuw te ssh, het zou moeten werken
Antwoord 13, autoriteit 4%
probeer met optie -NT
ssh -NT …
Antwoord 14
het opnieuw koppelen van /dev/pts werkt voor mij. je kunt dit op afstand doen via ssh als je ssh op deze manier uitvoert tegen de getroffen machine. ssh vraagt geen tty bij het uitvoeren van dit soort commando’s en daarom kun je /dev/pts op afstand opnieuw aankoppelen
ssh gebruiker@host — ‘mount -o remount,rw /dev/pts’
Antwoord 15
Ik zie dit af en toe bij het opstarten van een VM. Ons automatiseringssysteem begint updates toe te passen, dus afhankelijk van de timing kan er een update plaatsvinden voor kritieke pakketten.
Upshot – dit kan gebeuren als ssh of andere gerelateerde pakketten worden bijgewerkt op de doelcomputer.
Antwoord 16
Ik ben deze fout tegengekomen tijdens het gebruik van mijn git bash. Ik heb dit kunnen oplossen door git voor Windows opnieuw te installeren. Meer details in dit antwoord.
Antwoord 17
Mocht een persoon deze QA lezen terwijl hij probeert te sshnaar een NetGear ReadyNAS-apparaat, zorg er dan voor dat het selectievakje “Alleen rsync” uitis aangevinkt het dialoogvenster voor de ssh-service in de beheerdersinterface.
Antwoord 18
Dit gebeurde toen ik sudo probeerde te gebruiken op ssh -t [email protected]nadat ik de openbare sleutel van mijn lokale gebruiker aan github had toegevoegd
Gewoon een voorsprong op de Google-gelukkige mensen zoals ik
Antwoord 19
Alleen het opnieuw opstarten van een AWS-instantie werkt voor mij om de fout “shell-verzoek mislukt op kanaal 0” te wissen
Antwoord 20
Omdat je de vlag -T die een PTY maakt al hebt gevonden, zal ik alleen reageren op het tweede deel:
shell-verzoek mislukt op kanaal 0
Je moet een commando doorgeven:
ssh [email protected] -p 22 help
Na het teruglezen van de handleiding hier: https://www.jenkins.io /doc/book/managing/cli/, ik vind het niet echt duidelijk dat het niet zou werken zonder een commando. Maar zoals aangegeven door @U.V., is de ssh-interface geen console-interface, eerder een verbindingshulpprogramma. Dus je moet een commando doorgeven…
Als iemand van het “jenkins”-team dit bericht tegenkomt, zou het geweldig zijn dat als we geen commando doorgeven, de hulp zou verschijnen 🙂
Antwoord 21
Als je bent verbonden met EC2 EC2 Serial Consoleen SSH probeert uit te voeren vanaf je lokale computer, krijg je deze foutmelding, dus sluit EC2 Seriële Consoleen maak opnieuw verbinding SSH het zal worden opgelost.