How to Fix Shell Request Failed on Channel 0

Secure Shell or better known SSH is a network protocol that enables two computers to communicate. This protocol allows the users, especially system administrators to access a computer over an unsecured network. In other words, its system allows the users to share the data.

Unfortunately, when you are working with SSH, you will face the error that shows ‘shell request failed on channel 0’. This error will be quite frustrating for you, right? No worries! This post will show you some guides to fix the error message of ‘shell request failed on channel 0’. Let’s dive into our post below!

What is the Cause of the Shell Request Failed on Channel 0 Error Message?

The SSH error of ‘shell request failed on channel 0’ will appear when SSH (Secure Shell) login is attempted. This error basically happens when the SSH server is not assigning a TTY instance for the connection. In short, it will affect the interactivity in the shell.

Well, it typically occurs when an SSH command has an alias set on the server. For the symptom, the ‘shell request failed on channel 0’ error message appears when the system is inaccessible via SSH (Secure Shell).

The error also occurs when running SSHD in debug mode:

    • Stop sshd: # stopsrc -s sshd
    • Start up a script session: # script /tmp/sshd.debug
    • Start up sshd in debug mode: # /usr/sbin/sshd -d -d -d -d
    • Recreate ssh issue by trying to establish a new SSH session
    • Stop script session: # exit
    • Restart sshd: # startsrc -s sshd
    • /tmp/sshd.debug file will contain an entry similar to: do_exec_pty: sem_init: no space left device

Here’s a List of Diagnosing the Problems!

The diagnosing the problem can be performed by verifying there are not too many semaphores that are held by a certain process or user. Well, the output will be similar to the following list with successive parts:

T,  ID, KEY, MODE, OWNER, GROUP, CREATOR, CGROUP, NSEMS, OTIME , CTIME

    • m 1048576 0xffffffff D-rw——- root system root system 1 268435456 2818362 2818362 16:14:51 no-entry 16:14:51
    • m 1048577 0xffffffff D-rw——- root system root system 1 536870912 2818362 2818362 16:14:51 no-entry 16:14:51
    • m 9437192 0xffffffff D-rw——- user1 dstage user1 dstage 1 268435456 3801374 3801374 16:15:10 no-entry 16:15:10
    • m 9437193 0xffffffff D-rw——- user1 dstage user1 dstage 1 537329664 3801374 3801374 16:15:10 no-entry 16:15:10
    • m 1048586 0xadecb500 –rw-rw-rw- root system root system 19 27447484 6553752 19988504 12:12:00 12:12:03 16:14:54
    • m 5242891 0xffffffff D-rw——- user1 dstage user1 dstage 1 268435456 3801374 3801374 16:15:10 no-entry 16:15:10
    • m 12 0xadeeb500 –rw-rw-rw- root system root system 19 4851604 5701664 19988504 12:12:00 12:12:03 16:14:54
    • m 1048591 0xffffffff D-rw——- user1 dstage user1 dstage 1 65536 7798922 7798922 16:15:11 no-entry 16:15:11
    • m 1048593 0xffffffff D-rw——- user1 dstage user1 dstage 1 65536 7798922 7798922 16:15:11 no-entry 16:15:11
    • m 18 0xffffffff D-rw——- user1 dstage user1 dstage 1 268435456 7798922 6815806 16:15:1

Here are more example of 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

How to Fix Shell Request Failed on Channel 0?

We definitely get the guide to fix the ‘Shell Request Failed on Channel 0’ error message from some sources. We found two methods that you can perform in order to fix this error message when working with SSH. Here they are:

Method 1: Unmounting and Remounting /dev/pts

It is known that one of the reasons for SSH channel error is in the incorrect mount option set for /dev/pts. This is a virtual filesystem in the kernel for the pseudo-terminal. Generally, init scripts or daemons like systemd will take care of the appropriate mounting of the devpts filesystem.

Generally, there will be a limit of 256 pseudo terminals on a system. In this case, SSH returns TY allocation failure when any application running on the server begins leaking pseudo terminals.

To fix the ‘shell request failed on Channel 0’, you can try unmounting and remounting /dev/pts. Let’s use the following command:

    • $ umount /dev/pts
    • $ mount devpts /dev/pts -t devpts

That said, this command really fixes the error effectively. If the server becomes inaccessible, you can try to reboot the server to single user mode. Then, add those lines to your /etc/mtab & /etc/fstab entry.

To do this, you can open the file /etc/mtab or /etc/fstab. Then, add the line into those files. none /dev/pts devpts defaults 0 0

Last, you can reboot the system to make the changes effectively and greatly.

Method 2: Through SSH Settings

Incorrect SSH settings will also cause the error to occur. (i.e. when the SSH binary is aliased to ‘ssh-t’, it will result in an error. Furthermore, the same error will pop up when accessing PTY is forbidden in the .ssh/authorized_keys file.

Alternatively, when the SSH configuration file holds entries like ‘PermitTTY yes’, it may be able to cause the TTY error. Finally, it will result in a failed login. Therefore, you can edit the configuration and adjust the entry as follow:

PermitTTY no

That said, it will fix the issue and make SSH working again.

Well, those are two methods that you can use to try fixing the SSH error message that says ‘shell request failed on channel’. Good Luck!!!

Related Posts