SSH fails: PTY allocation request failed on channel 0

Question

So I googled the error and checked serverfault, but the solutions didn't fit. Most results were problems with /dev/pts, but that is mounted. Other results are errors with git, but there is no git on the machine.

My account isn't blocked, I can still log in on the console. Other users also have this problem, so I don't think it has something to do with something that's in my .ssh/

I get this response with ssh -vv:

<snip>
debug1: Next authentication method: password
rogier@server's password: 
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug2: channel 0: request shell confirm 1
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 100 id 0
PTY allocation request failed on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0

After this the session freezes. Does anyone have any idea what's going on?

Answer 1

Ok, thanks to Tim. umounting /dev/pts and then mount /dev/pts did the trick.

Answer 2

let me tell you all my experience, I try to connect from linux to windows via ssh, had servers with openssh and others with freessh. When the server has openssh it work fine, but since a time to now it start to present a "shell request failed on channel 0" message when freessh is the service running (it came from one day to another, it use to work better that openssh)

A test made by me was to try stablish conection from another user, as i see that it works fine, I backup my ~/.ssh (the user that present the problem), and after that it works fine.

I think the file involved was known_hosts, the perms looks fine as well as the content, but that was how I fix it.

Answer 3

The error just means that opening the pseudo terminal failed. Most likely it has nothing to do with ssh. To debug it on the ssh server side use a very simple PTY demo like mypty in http://rachid.koucha.free.fr/tech_corner/pty_pdip.html to see whether any PTY can be allocated at all. If not, use strace to investigate where it fails. (For me it was a missing /dev/ptmx symlink in a container as explained in https://www.kernel.org/doc/Documentation/filesystems/devpts.txt )

Answer 4

While mounting again I get,

warning: can't open /etc/fstab: No such file or directory

But,

mount devpts /dev/pts -t devpts

do the trick

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

Answer 5

Could depend on you LANG and your LC settings, but this works for me:

unset LANG        2>/dev/null
unset LC_MONETARY 2>/dev/null
unset LC_NUMERIC  2>/dev/null
unset LC_MESSAGES 2>/dev/null
unset LC_COLLATE  2>/dev/null
unset LC_CTYPE    2>/dev/null
ssh -l username hostname

Answer 6

In my case, I was connecting to a Windows host (running cygwin and other related softwares) from a Linux box.

Strangely attempts to connect to windows server did work but failed while allocating interactive terminal. Check ssh -vv logs below.

...
Authentication succeeded
...
Entering interactive session
Requesting authentication agent forwarding.
Sending environment.
Sending env LANG = en_US.UTF-8
PTY allocation request failed on channel 4
...

My colleague figured out that it was because of many open processes on windows server which was using the same login credentials as mine and doing some automated batch operation.

Killing it temporarily, did the trick, and allowed my ssh connection successfully.

Most likely, windows + cygwin, had max limit in that regards. Work remains to de-allocate resources correctly when those processes are done running.

Answer 7

I've just had this same issue when trying to SSH in to any machine after I had been playing around with generating new SSH certificates. Re-mounting /dev/pts didn't do anything for me, but clearing the identities from my local ssh-agent did work:

ssh-add -D