gitolite: PTY allocation request failed on channel 0

Question

Both jenkins (the ci-server) and my git repository are hosted on the same server. The git repo is controlled by gitolite. If I access the repository from outside, for instance from my workstation I get

ssh git@arrakis

PTY allocation request failed on channel 0
hello simou, this is git@arrakis running gitolite3 v3.0-12-ge0ed141 on git 1.7.3.4

 R W    testing
Connection to arrakis closed.

Which is fine I guess (besides the PTY... warning)

Now back to the server, I'd like jenkins to be able to connect to my git repository as well.

jenkins@arrakis:~> ssh git@arrakis
gitolite: PTY allocation request failed on channel 0

Logging onto arrakis as user git (the gitolite user):

git@arrakis:~> cat ~git/.ssh/authorized_keys

command="/home/git/gitServer/gitolite/src/gitolite-shell jenkins",no-port-forwarding,no-x11-forwarding,no-agent-forwarding,no-pty ssh-rsa <PUBLIC-KEY> jenkins@arrakis

The "no-pty" entry made me suspicious, so I removed it from authorized_keys and tried again:

jenkins@arrakis:~> ssh git@arrakis
hello jenkins, this is git@arrakis running gitolite3 v3.0-12-ge0ed141 on git 1.7.3.4

 R W    testing
Connection to arrakis closed.

This solves my issue at this point, but I'm not sure about the consequences of removing "no-pty".

And why does it only affect the local access, since the remote access doesn't seem to be affected at all?

---

openSUSE 11.4 (x86_64) VERSION = 11.4 CODENAME = Celadon

Answer 1

The difference in behavior between your workstation and your server is likely due to using different versions of the OpenSSH client (ssh) on each system (not remote versus local). The client will request a pty from the server unless -T is given, or the RequestTTY configuration option is set to no (the latter was first available in OpenSSH 5.9). The difference in behavior arises in how the client deals with having this request denied by the server (e.g. because no-pty is given in the applicable authorized_keys entry):

• Before OpenSSH 5.6:
  • the client will display the “PTY allocation request failed” message, and
  • continue in “no pty” mode
• In OpenSSH 5.6-5.8:
  • the client will display the “PTY allocation request failed” message, and
  • abort the connection
• In OpenSSH 5.9 (and later):
  • the client will display the “PTY allocation request failed” message, and
  • if -t was not given, and RequestTTY is auto (the default), then
    • continue in “no pty” mode
  • else (-t given, or the RequestTTY configuration option is yes or force)
    • abort the connection

Since your server’s ssh appears to abort when its pty allocation request is rejected, it is probably running OpenSSH 5.6-5.8 (at least for the client binary). Likewise, since your workstation’s ssh shows the warning, but continues, it is probably running an OpenSSH from before 5.6, or one that is 5.9-or-later. You can check your versions with ssh -V.

You can prevent the difference in behavior by using always giving the -T option so that the client (any version) never requests a pty from the server:

ssh -T git@YourServer

During actual Git access, the client never tries to allocate a pty because Git will give the client a specific command to run (e.g. ssh server git-upload-pack path/to/repository) instead of requesting an “interactive” session (e.g. ssh server). In other words, no-pty should not have been causing problems for actual Git access; it only affected your authentication testing (depending on which version of the OpenSSH client you were running) because the lack of a command argument causes an implicit pty allocation request (for an “interactive” session).

---

From the OpenSSH 5.6 release announcement:

• Kill channel when pty allocation requests fail. Fixed stuck client if the server refuses pty allocation (bz#1698)

bz#1698 seems to be a reference to a report logged in the “Portable OpenSSH” Bugzilla.

---

From the check-in message of OpenSSH clientloop.c rev 1.234:

improve our behaviour when TTY allocation fails: if we are in RequestTTY=auto mode (the default), then do not treat at TTY allocation error as fatal but rather just restore the local TTY to cooked mode and continue. This is more graceful on devices that never allocate TTYs.

If RequestTTY is set to "yes" or "force", then failure to allocate a TTY is fatal.