gitolite: PTY allocation request failed on channel 0 - gitolite

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.

Answer 2

To know why it affects only the local access, you would need to debug it like in this article.
ssh -vvv git#arrakis
If your /etc/ssh/sshd_config SSH daemon config file contains the (un-commented) line SyslogFacility AUTHPRIV, you can have a look at your SSH logs in /var/log/secure.
That being said, check out GitoliteV3: I don't think it uses no-pty in the current setup.

Answer 3

Beside Chris Johnsen very complete answer note that giving explicitely the info command will not show the PTY warning:
ssh git#arrakis info
In that case SSH considers that this is not an interactive session and will not request a TTY.