web-dev-qa-db-ja.com

gitolite：PTY割り当て要求はチャネル0で失敗しました

Jenkins（ci-server）と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 ...警告以外）

サーバーに戻って、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コードネーム= Celadon

gitolite
25
simou

ワークステーションとサーバーの動作の違いは、各システムで異なるバージョンのOpenSSHクライアント（ssh）を使用しているためである可能性があります（リモートではなくローカル）。 -Tが指定されていない場合、またはRequestTTY構成オプションがnoに設定されていない限り、クライアントはサーバーからptyを要求します（後者はOpenSSH 5.9で最初に利用可能になりました）。動作の違いは、クライアントがサーバーによってこの要求を拒否する方法に対処する方法で発生します（たとえば、no-ptyが該当するauthorized_keysエントリで指定されているため）。

  • OpenSSH 5.6より前：
    • クライアントは「PTY割り当て要求に失敗しました」というメッセージを表示します。
    • continue「no pty」モードで
  • OpenSSH 5.6-5.8：
    • クライアントは「PTY割り当て要求に失敗しました」というメッセージを表示します。
    • abort接続
  • OpenSSH 5.9（以降）の場合：
    • クライアントは「PTY割り当て要求に失敗しました」というメッセージを表示します。
    • -tが指定されておらず、RequestTTYがauto（デフォルト）の場合、
      • continue「no pty」モードで
    • else（-tが指定されている、またはRequestTTY構成オプションがyesまたはforceである）
      • abort接続

サーバーのsshは、pty割り当て要求が拒否されたときに中断するように見えるため、おそらく（少なくともクライアントバイナリに対して）OpenSSH 5.6-5.8を実行しています。同様に、ワークステーションのsshは警告を表示しますが、継続するため、おそらく5.6以前または5.9以降のOpenSSHを実行しています。 ssh -Vでバージョンを確認できます。

クライアント（すべてのバージョン）がサーバーからptyを要求しないように、常に-Tオプションを指定することで、動作の違いを防ぐことができます。

ssh -T git@YourServer

実際のGitアクセス中、クライアントはptyを割り当てようとしません。これは、Gitが「インタラクティブ」セッション（例：ssh server git-upload-pack path/to/repository）を要求する代わりに、クライアントに実行する特定のコマンド（例：ssh server）を与えるためです。言い換えれば、no-ptyは実際のGitアクセスに問題を引き起こしてはならないはずです。コマンド引数がないために暗黙的なpty割り当て要求が発生するため（「インタラクティブ」セッションの場合）、認証テスト（実行しているOpenSSHクライアントのバージョンに依存）にのみ影響します。

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の割り当てに失敗すると致命的です。

48
Chris Johnsen

ローカルアクセスのみに影響する理由を知るには、 この記事 のようにデバッグする必要があります。

ssh -vvv git@arrakis

/etc/ssh/sshd_config SSHデーモン設定ファイルに（コメント化されていない）行SyslogFacility AUTHPRIVが含まれている場合、/var/log/secureでSSHログを確認できます。

とはいえ、チェックアウト GitoliteV ：現在のセットアップではno-ptyを使用しているとは思わない。

2
VonC

クリス・ジョンセンの他に、infoコマンドを明示的に指定してもPTY警告は表示されないという非常に完全な回答ノート：

ssh git@arrakis info

その場合、SSHはこれが対話型セッションではないと見なし、TTYを要求しません。

1
dolmen