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

Question

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 = Celadon

Answer 1

工作站和服务器之间的行为差​​异可能是由于ssh在每个系统上使用不同版本的OpenSSH客户端()(不是远程与本地).除非-T给出,否则客户端将从服务器请求pty ,或者RequestTTY配置选项设置为no(后者首先在OpenSSH 5.9中可用).行为的差异产生于客户端如何处理服务器拒绝此请求(例如,因为no-pty在适用的authorized_keys条目中给出):

• 在OpenSSH 5.6之前:
  • 客户端将显示"PTY allocation request failed"消息,并且
  • 继续 "无pty"模式
• 在OpenSSH 5.6-5.8中:
  • 客户端将显示"PTY allocation request failed"消息,并且
  • 中止连接
• 在OpenSSH 5.9(及更高版本)中:
  • 客户端将显示"PTY allocation request failed"消息,并且
  • 如果-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 server).换句话说,no-pty不应该导致实际的Git访问问题; 它只会影响您的身份验证测试(取决于您运行的OpenSSH客户端的版本),因为缺少命令参数会导致隐式的pty分配请求(对于"交互式"会话).

从OpenSSH 5.6发布公告:

• 当pty分配请求失败时终止通道.如果服务器拒绝pty分配,则修复卡住的客户端(bz#1698)

bz#1698似乎是对"Portable OpenSSH"Bugzilla中记录的报告的引用.

从OpenSSH clientloop.c rev 1.234的签入消息:

当TTY分配失败时改善我们的行为:如果我们处于RequestTTY = auto模式(默认值),则不要将TTY分配错误视为致命,而是将本地TTY恢复为熟化模式并继续.在从不分配TTY的设备上更优雅.

如果RequestTTY设置为"yes"或"force",则分配TTY失败是致命的.