如何修复通道0请求失败

小开

PTY allocation request failed on channel 0

There is a limit of 256 pseudo terminals on a system. Maybe you have an application that is leaking pseudo terminals. Use

lsof /dev/pts/*

to see what processes have open pseudo-terminals

shell request failed on channel 0

I was getting this error (without PTY allocation error). It turns out that one of my applications (QtCreator 3.0.?) was leaking Zombie processes. Other users were able to log in so I might have been hitting my per user process quota (if there is such a thing). I've updated to QtCreator 3.3. So far so good.

小开

Just add these lines to your /etc/mtab and /etc/fstab, and reboot the system.

none    /dev/pts    devpts    defaults    0    0

小开

I solved a similar problem with one of our users who was used only for ssh port forwarding so he don't need to have access to PTY and it was prohibited in .ssh/authorized_keys file:

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

So when you tried to log in to this user, only message

PTY allocation request failed on channel 0

was returned. So check your user's authorized_keys file.

小开

unmount and mount /dev/pts worked for me

umount /dev/pts


mount devpts /dev/pts -t devpts

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

小开

I had the exact same error trying to connect via ssh to my server. As I can see you're using a server provided by Hetzner connecting to it on port 22:

debug1: Connecting to xxx.your-server.de [188.40.3.15] port 22.

The offical wiki/documention from Hetzner says:

Protocol for encrypted remote diagnostics for servers/computers(consoles). The SSH port to be used is 222.

So you have to connect via port 222:

ssh -p 222 username@my-server.de

小开

rebooting the instance from AWS console worked for me. There was a service that was leaking file connections that lsof helped find.

小开

It's an old question, but if someone gets here like me...

This might be result of a wrong date in the server. If you are working with an embedded system this might be the cause... So check your date:

$ date

小开

shell request failed on channel 0

mean you don't have shell or remote commands access, fix your user permission on server to have shell access or if you just want tunneling use -N and -T options

小开

Try this:

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

小开

remounting /dev/pts works for me. you can do this remotely via ssh if you run ssh like this against the affected machine. ssh doesn't request a tty when running commands like this and therefore this will allow you to remount /dev/pts remotely

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

小开

just found out, what was the problem in my case (provider strato): I had the same problem with output "shell request failed on channel 0" in the end.

I have to use the master password with the web-domain name as login. (In German www.wunschname.de, where wunschname is your web-address.)

A ssh login with sftp-user names and the corresponding passwords is without success. (Although scp and sftp works with these sftp users!)

小开

I occasionally see this when spinning up a VM. Our automation system starts applying updates, so depending on timing can hit an update to critical packages.

Upshot - this might happen if ssh or other related packages are being updated on the destination machine.

小开

I encountered this error while using my git bash. I was able to solve this by re-installing git for windows. More details in this answer.

小开

I also faced the same issue. Just restarting my servers solved the issue.

小开

Should a person find themselves reading this QA while they are trying to ssh into a NetGear ReadyNAS device, be sure that the "rsync only" checkbox is unchecked in the dialog box for the ssh service in the admin interface.

小开

This was happening when I was trying to use sudo on ssh -t git@github.com after adding my local user's public key to github

Just a head's up to the google happy people like me

小开

Just rebooting a AWS instance works for me to clear the error shell request failed on channel 0

小开

This is what which helped me from the various answers provided.

Try logging in as root, that will get you in most of the times
Try logging in as a different user, it successful, it means that the problem is with a specific account & it implies that there are some process(es) already started by the problematic account which are consuming resources preventing login(most likely no of processes)
Increase the limit in /etc/security/limits.d/20-nproc.conf as mentioned by xmduhan above
Try to ssh again, it should work

小开

try with option -NT

ssh -NT ...

小开

As you already found the -T flag that create a PTY, I will just respond to the second part:

shell request failed on channel 0

You should pass a command:

ssh username@my-server.de -p 22 help

After reading back the manual here: https://www.jenkins.io/doc/book/managing/cli/, I find it not really clear that it would not work without a command. But as stated by @U.V., the ssh interface is not a console interface, rather a connection utility. So you need to pass a command...

If someone from the "jenkins" team pass accross this post, it would be great that if we pass no command, the help would show up :-)

小开

If you are trying to test your github ssh key write

ssh -T git@github.com

instead of ssh -t git@github.com

小开

If you come to this Q&A for sftp while ssh is working, and you are getting:

subsystem request failed on channel 0

make sure /etc/ssh/sshd_config contains the following line(s):

# override default of no subsystems
Subsystem       sftp    /usr/libexec/openssh/sftp-server

They are there by default, but might have been removed for hardening purposes.

小开

In my case, my sshd_config contained the value

PermitTTY No

I have to change this to

PermitTTY yes

To log in, I used ssh user@address /bin/bash -i

This gives me a shell without PTY. I then used sed to edit the file:

sed -e '/PermitTTY.*/PermitTTY yes/' < /etc/ssh/sshd_config > sshd_new

Then

sudo -S cp sshd_new /etc/ssh/sshd_config