gpt4 book ai didi

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

转载 作者:行者123 更新时间:2023-12-02 17:53:47 25 4
gpt4 key购买 nike

jenkins(ci 服务器)和我的 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)版本 = 11.4代号 = 青瓷

最佳答案

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

  • OpenSSH 5.6 之前:
    • 客户端将显示“PTY 分配请求失败”消息,并且
    • 继续“无 pty”模式
  • 在 OpenSSH 5.6-5.8 中:
    • 客户端将显示“PTY 分配请求失败”消息,并且
    • 中止连接
  • 在 OpenSSH 5.9(及更高版本)中:
    • 客户端将显示“PTY 分配请求失败”消息,并且
    • 如果未给出 -t,且 RequestTTYauto(默认值),则
      • 继续“无 pty”模式
    • else(给定-t,或者RequestTTY配置选项为yesforce)
      • 中止连接

由于您的服务器的 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)请求“交互式” session (例如 ssh 服务器)。换句话说,no-pty 不应该给实际的 Git 访问带来问题;它只影响您的身份验证测试(取决于您运行的 OpenSSH 客户端版本),因为缺少命令参数会导致隐式 pty 分配请求(对于“交互式” session )。

<小时/>

来自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: channel 0 上的 PTY 分配请求失败,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/10330678/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com