How to fix request failed on channel 0

Question

When I want to connect to my server like this

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

Answer 1

try with option -NT

ssh -NT ...

Answer 2

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.

Answer 3

Try this:

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

Answer 4

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

Answer 5

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

Answer 6

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

Answer 7

If you are trying to test your github ssh key write

ssh -T [email protected]

instead of ssh -t [email protected]

Answer 8

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

Answer 9

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

Answer 10

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

Answer 11

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.

Answer 12

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

Answer 13

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'

Answer 14

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

Answer 15

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.

Answer 16

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

Answer 17

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

Answer 18

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

Answer 19

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

none    /dev/pts    devpts    defaults    0    0

Answer 20

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.

Answer 21

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

Answer 22

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.

Answer 23

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.