PTY allocation request failed on channel 0

12,088

Solution 1

It appears like the server operator has adjusted the sshd configuration or setup options in the authroized_keys files to prevent you from getting an interactive shell. Server operators that want to provide sftp access only frequently do this.

debug1: Remote: Forced command.
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.
debug1: Remote: Forced command.
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.

Try connecting without using your keys for authentication. If you can get a shell when you don't use a key the problem is in your authorized_keys file. If you cannot login when trying to use password authentication, and password authentication isn't disabled, then the problem is going to be in the sshd_config.

Solution 2

I had the same problem. Some gitolite configuration step had added another restrictive set of key that was causing problem. The problematic server side .ssh/authorized_keys had


ssh-rsa XXY-my-original-keyXXX some_name

#gitolite start

command="/usr/share/gitolite/gl-auth-command ubuntu",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa XXY-some-gitolite-keyXXX some_other_name

#gitolite end


I removed the gitolite section and I too was golden

Share:
12,088

Related videos on Youtube

loeschg
Author by

loeschg

Updated on September 18, 2022

Comments

  • loeschg
    loeschg almost 2 years

    I recently ran into the following problem when trying to ssh into my Ubuntu 11.04 server:

    ssh [email protected]
    PTY allocation request failed on channel 0

    I don't know for sure, but I think this happened after one of the latest Ubuntu updates I installed. In case it's of relevance, I'm remoting in from Terminal (Mac OS X 10.7 - Lion).

    EDIT: It turns out that I can remote in as another user (i.e. matt) on my server... seems to me like that would point to SSH key problems. If I remote in from another account on the same client machine, it works fine for all users on the server.

    SOLUTION: Turns out that I had gitolite configurations in my ~/.ssh/allowedkeys on the server side. I accidentally ran a configuration script some time ago as my user instead of as the git user. This was kicking off configurations upon remote (keys matched up) that disabled needed settings (see below). I removed the relevant fields from allowedkeys, and I was golden.

    debug1: Remote: Forced command.
    debug1: Remote: Port forwarding disabled.
    debug1: Remote: X11 forwarding disabled.
    debug1: Remote: Agent forwarding disabled.
    debug1: Remote: Pty allocation disabled.
    debug1: Remote: Forced command.
    debug1: Remote: Port forwarding disabled.
    debug1: Remote: X11 forwarding disabled.
    debug1: Remote: Agent forwarding disabled.
    debug1: Remote: Pty allocation disabled.
    PTY allocation request failed on channel 0
    
    • ravi yarlagadda
      ravi yarlagadda almost 13 years
      Pty allocation disabled. - what's your sshd_config look like?
    • loeschg
      loeschg almost 13 years
      @Shane - I updated the post above with my sshd_config file. I also added other relevant info... turns out I can log in as 'user' from another account on the client machine. I can also remote in as a different server user on the problematic local account (sorry... a little convoluted... should make sense).
  • loeschg
    loeschg almost 13 years
    I added relevant info to my original post (see bold above). I'm not entirely sure how to try authenticating without a key. I tried removing .ssh completely from my local/client machine. I was prompted to add the server to known hosts, I said 'yes', and got the PTY allocation error.
  • loeschg
    loeschg almost 13 years
    Got it figured out. You got me going down the right path. Thanks @Zoredache.