How to fix request failed on channel 0

When I want to connect to my server like this

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

it gives me two error messages:

PTY allocation request failed on channel 0
shell request failed on channel 0

When I use the parameter -T the first error message goes away. But how to fix the second one? I can't connect. To other servers I can connect without any problems.

I'm on MAC OS 10.9.

The parameter -v shows me this debug output:

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

After I enter the password, I get this:

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

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

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

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.

Try this:

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

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

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

none    /dev/pts    devpts    defaults    0    0

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!)

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

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

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

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

If you are trying to test your github ssh key write

ssh -T [email protected]

instead of ssh -t [email protected]

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'

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.

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 [email protected] after adding my local user's public key to github

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

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 [email protected] -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 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.