gitolite:通道0上的PTY分配请求失败

jenkins(ci-server)和我的git存储库都托管在同一个服务器上。 git repo由gitolite控制。如果我从外部访问存储库,例如从我的工作站获取

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.

这是很好的我猜(除了PTY …警告)

现在回到服务器,我希望jenkins能够连接到我的git仓库。

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

用户git(gitolite用户)登录arrakis:

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

“no-pty”条目让我怀疑,所以我把它从authorized_keys中删除,并再次尝试:

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.

这样解决了我的问题,但是我不知道删除“no-pty”的后果。

为什么只影响本地访问,因为远程访问似乎没有受到影响?

openSUSE 11.4(x86_64)
VERSION = 11.4
CODENAME =青瓷

最佳答案
您的工作站和服务器之间的行为差​​异可能是由于在每个系统(而不是远程与本地)上使用不同版本的OpenSSH客户端(ssh)。客户端将从服务器请求一个pty,除非给出-T,否则RequestTTY配置选项被设置为no(后者首次在OpenSSH 5.9中可用)。行为上的不同之处在于客户端如何处理服务器拒绝该请求(例如因为在可用的authorized_keys条目中没有提供):

> OpenSSH 5.6之前:

>客户端将显示“PTY分配请求失败”消息,以及
>继续在“无pty”模式

>在OpenSSH 5.6-5.8中:

>客户端将显示“PTY分配请求失败”消息,以及
>中止连接

>在OpenSSH 5.9(及更高版本)中:

>客户端将显示“PTY分配请求失败”消息,以及
>如果没有给出-t,并且RequestTTY是auto(默认),那么

>继续在“无pty”模式

> else(-t给定,或者RequestTTY配置选项为yes或force)

>中止连接

由于您的服务器的ssh似乎在其pty分配请求被拒绝时中止,因此可能运行OpenSSH 5.6-5.8(至少对于客户端二进制文件)。同样,由于您的工作站的ssh显示警告但是继续,它可能在5.6之前运行OpenSSH,或者是5.9或更高版本的OpenSSH。您可以使用ssh -V检查您的版本。

您可以通过使用始终提供-T选项来防止行为的差异,以便客户端(任何版本)从不从服务器请求pty:

ssh -T git@YourServer

在实际的Git访问期间,客户端不会尝试分配一个pty,因为Git会给客户端一个特定的运行命令(例如ssh server git-upload-pack path / to / repository),而不是请求一个“交互式”会话(例如ssh服务器)。换句话说,no-pty不应该导致实际Git访问的问题;它仅影响您的身份验证测试(取决于您正在运行的OpenSSH客户端版本),因为缺少命令参数会导致隐式的pty分配请求(对于“交互式”会话)。

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似乎是report logged in the “Portable OpenSSH” Bugzilla的参考。

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.

转载注明原文:gitolite:通道0上的PTY分配请求失败 - 代码日志