gitolite: сбой запроса на выделение PTY на канале 0

оба jenkins (ci-сервер) и мой репозиторий git размещены на одном сервере. РЕПО git контролируется 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... предупреждение)

теперь вернемся к серверу, я хотел бы, чтобы Дженкинс мог подключиться к моему репозиторию git.

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

вход на arrakis как пользователь git (гитолит пользователь):

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 Кодовое имя = Celadon

25
gitolite

3 ответов

разница в поведении между вашей рабочей станцией и вашим сервером, вероятно, связана с использованием разных версий клиента OpenSSH (ssh) в каждой системе (не удаленной по сравнению с локальной). Клиент будет запрашивать pty с сервера, если -T или RequestTTY параметр конфигурации установлен в no (последний был впервые доступен в OpenSSH 5.9). Разница в поведении возникает в том, как клиент имеет дело с тем, что этот запрос отклонен сервером (например, потому что no-pty приведено в применимом authorized_keys запись):

  • Прежде Чем Пакет OpenSSH 5.6:
    • клиент отобразит сообщение "сбой запроса на выделение PTY" и
    • дальше в режиме "нет pty"
  • В OpenSSH 5.6-5.8:
    • клиент отобразит сообщение "сбой запроса на выделение PTY" и
    • отмена the связи
  • в OpenSSH 5.9 (и более поздних версиях):
    • клиент отобразит сообщение "сбой запроса на выделение PTY" и
    • если -t не дали, а RequestTTY is auto (по умолчанию), затем
      • дальше в режиме "нет pty"
    • else (-t или RequestTTY настройка yes или force)
      • отмена the связи

так как ваш сервер ssh похоже, прерывается, когда его запрос на выделение pty отклонен, он, вероятно, работает OpenSSH 5.6-5.8 (по крайней мере, для двоичного файла клиента). Аналогично, поскольку ваша рабочая станция ssh показывает предупреждение, но продолжает, вероятно, работает OpenSSH до 5.6 или 5.9-или-позже. Вы можете проверить свои версии с помощью 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=автоматический режим (по умолчанию), затем не обрабатывать в TTY ошибка выделения как фатальная, а просто восстановить локальный TTY перейти в режим варки и продолжить. Это более изящно на устройствах, которые никогда не выделять TTYs.

если RequestTTY имеет значение "yes" или "force", то ошибка выделения терминал является смертельным.

46

чтобы узнать, почему это влияет только на локальный доступ, вам нужно будет отладить его как в этой статье.

ssh -vvv git@arrakis

если /etc/ssh/sshd_config файл-демон SSH config содержит (ООН-прокомментировал) строку SyslogFacility AUTHPRIV, вы можете посмотреть на свои журналы SSH в /var/log/secure.

Это, как говорится, проверить GitoliteV3: Я не думаю, что он использует no-pty в текущей настройке.

2

рядом с Крисом Джонсеном очень полный ответ обратите внимание, что давая явно info команда не покажет предупреждение PTY:

ssh git@arrakis info

в этом случае SSH считает, что это не интерактивный сеанс и не будет запрашивать TTY.

1