Pty allocation request failed on channel 0 windows

As described in the comments on the question, the “PTY allocation request failed” is a red herring with respect to GitHub authentication (it is the result of trying to interactively login to GitHub when the only SSH service they offer is non-interactive Git-over-SSH; the authentication is working, they just do not provide interactive, “shell” service).

The person who asked the question wrote this in a comment:

I guess the related problem is that when I try to create a new repository and «git push origin master» I return the following «Error: Permission to myemail@address.com/myapp denied to myusername. Fatal: the remote end hung up unexpectedly»

This seems more likely to be the actual problem. This seems to indicate that the remote named origin not configured to correctly point to a GitHub repository.

Check the output of git remote show -n origin. Probably the “Fetch URL” and the “Push URL” are the same. They should both look like this:

git@github.com:git-user-name/repository-name

When logging into GitHub on the web you can use either your account’s username or its associated email address. When pushing to repositories (or fetching from private repositories) you have to use your actual username (an email address will not work). It looks you are using your email address in there instead of just your GitHub username. To fix this, reconfigure the remote’s URL:

git remote set-url origin git@github.com:github-username/repository-name

Your username is displayed in many places on the GitHub web pages once you are logged in. The easiest place to find it is between your gravatar and the “Dashboard” link on the page header (you will see a silhouette icon if you do not have a gravatar configured). That same location links to your public profile page; this page’s URL should also end in your username.

Do you have trouble when logging into a server through ssh?

SSH errors are quite frustrating, especially when doing server changes at the last minute.

One such error is the pty allocation request failed on channel 0 error.

At Bobcares, we help server owners resolve SSH errors as part of our Server Management Services.

Today, let’s discuss the pty allocation request failed error and see how our Support Engineers fix it.

What is the pty allocation request failed on channel 0 error?

As the first step, let’s check the details of the error “pty allocation request failed on channel 0“.

It is one of the common errors that happen when we ssh into the server.

The error mainly occurs when the SSH server isn’t assigning a TTY instance for the connection. In simple words, this affects the interactivity in the shell.

This typically happens when SSH command has an alias set on the server.

One of our customers contacted us with a similar error. He was trying to connect to the server through ssh like this:

ssh  username@my-server.com -p 22

And, it gave the error message as:

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

How we fix the pty allocation error?

Now, we know the scenario that causes this pty allocation request failed error.

Let’s see the major causes and how our Support Engineers fix this error.

1. Incorrect Mount options

One of the top reasons for SSH channel error will be incorrect mount option set for /dev/pts.

The /dev/pts is a virtual filesystem in the kernel for the pseudo-terminal.  Usually, init scripts or daemons like systemd takes care of the proper mounting of the devpts filesystem. In general, there is a limit of 256 pseudo terminals on a system. And, when any application running on the server starts leaking pseudo terminals, SSH returns TY allocation failure.

Here, our Support Engineers first check and see what processes have open pseudo-terminals using:

lsof /dev/pts/*

And, fix the error by unmounting and remounting /dev/pts.

For this, we use the command:

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

And that resolves the error effectively.

In case, if the server becomes inaccessible, we suggest the customers reboot the server to single user mode and add these lines to your /etc/mtab & /etc/fstab entry.

To do this, we open the file /etc/mtab or /etc/fstab. Then after, we add the line into these files.

none /dev/pts devpts defaults 0 0

At last, we reboot the system to make the changes effective.

2. SSH settings

In a similar way, incorrect SSH settings can also trigger this error. For example, when the SSH binary is aliased to ‘ssh –t’ it can result in an error.

Additionally, the same error pops up when access to PTY is prohibited in .ssh/authorized_keys file.

Or when the SSH configuration file holds entries like “PermitTTY yes“, it can even cause the TTY error. Ultimately, this results in a failed login.

Therefore, we edit the configuration and set the entry as:

PermitTTY no

That fixes the problem and makes SSH working again.

[Need help to solve the pty allocation request failed on channel 0 error? We’ll help you.]

Conclusion

In short, the ssh pty allocation request failed on channel 0 error happens when the server isn’t assigning a TTY instance for the connection. Today’s write-up also discussed the reasons for this error and how our  Support Engineers fixed it for our customers.

@arnos https://github.com/arnos i just started looking at working on
SSL support today and surprisingly i think i got it working. I am testing
with direct port redirection and also with haproxy. both seem to be working
(still early to say, need to test further).

I had added the http to https redirection in the nginx config and it all
worked fine with the direct host port redirections but not with haproxy.

This server simply redirects HTTP connections to HTTPSserver {

listen *:80 default_server;
server_name {{YOUR_SERVER_FQDN}};
server_tokens off;
rewrite ^ https://$server_name$request_uri? permanent;}

Instead I removed the above and configured nginx to also serve requests on
port 80

server {
listen *:80 default_server; # e.g., listen 192.168.1.1:80; In most cases *:80 is a good idea
server_name {{YOUR_SERVER_FQDN}}; # e.g., server_name source.example.com;
server_tokens off; # don’t show the version number, a security best practice
root /home/git/gitlab/public;

Increase this if you want to upload large attachments

Or if you want to accept large git objects over http

client_max_body_size 20m;

individual nginx logs for this gitlab vhost

access_log /var/log/nginx/gitlab_access.log;
error_log /var/log/nginx/gitlab_error.log;

location / {
# serve static files from defined root folder;.
# @GitLab is a named location for the upstream fallback, see below
try_files $uri $uri/index.html $uri.html @GitLab;
}

if a file, which is not found in the root folder is requested,

then the proxy pass the request to the upsteam (gitlab unicorn)

location @GitLab {
# If you use https make sure you disable gzip compression
# to be safe against BREACH attack
# gzip off;

proxy_read_timeout 300; # Some requests take more than 30 seconds.
proxy_connect_timeout 300; # Some requests take more than 30 seconds.
proxy_redirect     off;

proxy_set_header   X-Forwarded-Proto $scheme;
proxy_set_header   Host              $http_host;
proxy_set_header   X-Real-IP         $remote_addr;
proxy_set_header   X-Forwarded-For   $proxy_add_x_forwarded_for;

proxy_pass http://gitlab;

}

Enable gzip compression as per rails guide: http://guides.rubyonrails.org/asset_pipeline.html#gzip-compression

location ~ ^/(assets)/ {
root /home/git/gitlab/public;
gzip_static on; # to serve pre-gzipped version
expires max;
add_header Cache-Control public;
}

error_page 502 /502.html;}

And surprisingly it works in both cases and the http to https redirection
somehow takes place. But maybe its because of some other fixes I have in
place.

Should I pull your changes and apply my changes on top of it or should i
just publish my work for you to review and test? What do you suggest?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/53#issuecomment-41463910
.

error: PTY allocation request failed on channel 0

Perfectly normal, expected, and not blocking (ie the ssh operation would pursue)

However, you did the installation as root, which is bad, especially when you consider the ssh Gitolite page:

If you’re installing gitolite, you’re a «system admin», like it or not.
If you’re using the default ssh mode (i.e., not http mode), ssh is a necessary skill. Please take the time to learn at least enough to get passwordless access working.

The key aspect to understand in Gitolite is its usage of forced command, in order to deny interactive shell and to intercept any command (including the git commands), allowing it to enforce access control to Git repos.

That means your ~root/.ssh/authorized_keys file contains line with:

command="/devit_home/users/vobadm/gitpoc/ce7/gitolite/bin/gitolite-shell gitoliteadm",no-port-forwarding,no-X11-for        warding,no-agent-forwarding,no-pty ssh-rsa AAAAB3N

The no-port-forwarding is responsible for that warning message «PTY allocation request failed on channel 0«. But that doesn’t prevent Gitolite operations to run properly.

See «how does gitolite use all this ssh magic?».

For ssh issue, look into «SSH troubleshooting».
You need to gain access to your server by another way than ssh, and remove the line beginning by command in ~root/.ssh/authorized_keys.

Do you know how I might use Telnet to redo the gitolite installation process?

Once logged as root:

• remove the line beginning by command in the ~root/.ssh/authorized_keys file.
• make sure your root public key is registered in that same file (so without any ‘command=‘ in front of it.

That will ensure a root access through ss.

Then redo the installation, but with a sudo git first.
you must be ‘git’ when doing that installation.

You must first generate on the client side an git private ssh key and a git.pub public key.
Copy the public key on the server: you will pass that public key to the gitolite install command.

And as Ryan mentions in his answer, uses

DiskStation> /volume1/homes/git/gitolite/install -ln

(in order to link the installation to ~git/bin instead of the «system path root-protected» /bin directory).