Gitolite: запрос распределения PTY не удалось на канале 0

Оба jenkins (ci-server) и мой репозиторий git размещаются на одном сервере. Репо git контролируется гитолитом. Если я получаю доступ к репозиторию извне, например, с моей рабочей станции, я получаю

ssh [email protected]

PTY allocation request failed on channel 0
hello simou, this is [email protected] running gitolite3 v3.0-12-ge0ed141 on git 1.7.3.4

 R W    testing
Connection to arrakis closed.

Я думаю, что это нормально (кроме предупреждения PTY...)

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

[email protected]:~> ssh [email protected]
gitolite: PTY allocation request failed on channel 0

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

[email protected]:~> 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> [email protected]

Запись "no-pty" сделала меня подозрительной, поэтому я удалил ее из authorized_keys и попробовал еще раз:

[email protected]:~> ssh [email protected]
hello jenkins, this is [email protected] 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 CODENAME = Celadon

Ответы

Ответ 1

Разница в поведении между вашей рабочей станцией и вашим сервером, вероятно, связана с использованием разных версий клиента OpenSSH (ssh) в каждой системе (не удаленной и локальной). Клиент запрашивает pty с сервера, если не указано значение -T, или для параметра конфигурации RequestTTY установлено значение no (последний был впервые доступен в OpenSSH 5.9). Разница в поведении возникает в том, как клиент имеет дело с тем, что этот запрос отклонен сервером (например, поскольку no-pty указан в соответствующей записи 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 показывают предупреждение, но продолжают, вероятно, работает OpenSSH от 5.6 до 5.9 или позже. Вы можете проверить свои версии с помощью ssh -V.

Вы можете предотвратить разницу в поведении, всегда добавляя параметр -T, чтобы клиент (любая версия) никогда не запрашивал pty с сервера:

ssh -T [email protected]

При фактическом доступе 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 в режим приготовления и продолжить. Это более грациозно на устройствах, которые никогда не выделяйте TTY.

Если RequestTTY установлен на "yes" или "force", то отказ выделить TTY является фатальным.

Ответ 2

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

ssh -vvv [email protected]

Если ваш конфигурационный файл /etc/ssh/sshd_config SSH daemon содержит строку (без комментариев) SyslogFacility AUTHPRIV, вы можете просмотреть свои журналы SSH в /var/log/secure.

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

Ответ 3

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

ssh [email protected] info

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