【ITニュース解説】SSH Connection Multiplexing: The Config That Saves You From "Too Many Authentication Failures"

SSHはシステムエンジニアにとって、サーバーへ安全に接続するための不可欠なツールである。多くのサーバーを管理する中で、「Too many authentication failures」というエラーに遭遇することがあるだろう。これは、認証の試行回数が上限を超えたため接続が拒否されたことを意味し、SSHの設定ファイルである~/.ssh/configの不適切な記述や複雑な設定が原因で発生することが多い。

このエラーを避け、SSH接続を効率化する強力な機能が「SSH接続多重化（Connection Multiplexing）」だ。これは、特定のサーバーに対して一度確立したTCP接続を、その後の複数のSSHセッションで再利用する技術である。最初の接続で認証が完了すれば、以降の接続はほぼ瞬時に行われるため、サーバーへの頻繁な接続や複数のセッションを同時に開く際に大幅な時間短縮と快適さを提供する。

接続多重化を有効にするには、~/.ssh/configに次の設定を追加する。ControlMaster autoはマスター接続を自動で作成し、他のセッションで利用することを指示する。ControlPath ~/.ssh/cm-%r@%h:%pは、マスター接続の制御に必要なUNIXソケットファイルをどこに作成するかを指定する。%rはユーザー名、%hはホスト名、%pはポート番号にそれぞれ置き換えられる。ControlPersist 600は、最後のSSHセッション終了後もマスター接続を600秒間（10分）維持することを指示し、短時間での再接続時の認証を省略する。

しかし、この接続多重化は「ProxyJump（踏み台サーバー経由の接続）」と組み合わせる際に問題を引き起こす場合がある。ProxyJumpは、インターネットから直接アクセスできない内部ネットワークのサーバーへ、踏み台サーバーを経由して接続する機能だ。この場合、SSHは踏み台サーバーと目的のサーバーそれぞれに対して異なる制御ソケットを必要とするが、デフォルトのControlPath設定では、すべてのSSH接続に対して同じパターンでソケットファイルを作成しようとする。これにより、踏み台サーバーと目的のサーバー間でソケットファイルのパスが衝突し、「Control socket connect failed」や「Too many authentication failures」といったエラーが発生する。

この問題の解決策は、踏み台サーバーと目的のサーバーでそれぞれ異なる制御ソケットパスを設定することである。踏み台サーバーの設定には、例えばControlPath ~/.ssh/cm-bastion-%r@%h:%pのように固有のプレフィックスを追加する。一方、目的のアプリケーションサーバーにはControlPath ~/.ssh/cm-%h-%r@%h:%pのように、ホスト名を含めることで、完全に分離されたソケットパスを確保する。これにより、SSHはどの接続がどのソケットを使用すべきかを明確に識別できる。

「Too many authentication failures」エラーは、認証キーの取り扱いに関する「IdentityFile Trap」という問題でも発生しやすい。システムエンジニアは通常、複数のSSHキーを管理し、ssh-agentに登録していることが多い。ssh-agentはこれらのキーを安全に保持し、SSH接続時に自動的に認証情報を提供する便利な機能である。しかし、ターゲットサーバーが特定の認証キーしか受け付けない場合や、サーバー側の認証試行回数に上限が設定されている場合に問題が生じる。ssh-agentに複数のキーが登録されていると、SSHクライアントはそれらを順番に試行する。もしターゲットサーバーが受け付けるキーがリストの後半にあり、かつ試行回数制限が低い場合、正しいキーが試される前にエラーが発生してしまう。

この状況を回避するには、SSHクライアントがどの認証キーを使用するかを明示的に制御する必要がある。~/.ssh/configファイルにIdentitiesOnly yesを設定する。このオプションは、ssh-agentに登録されている他のすべてのキーを無視し、設定ファイル内でIdentityFileディレクティブを使って明示的に指定されたキーのみを試行するようにSSHに指示する。さらに、複数のIdentityFileディレクティブを記述することで、キーの試行順序を自分でコントロールし、無駄な試行を減らすことができる。

SSH設定ファイルの記述順序も重要である。SSHクライアントは、設定ファイルを上から順に読み込み、各オプションに対して最初にマッチした設定を適用する。「Host *」のようなワイルドカード設定がファイルの先頭や、別のインクルードファイルに記述されている場合、予期せぬ挙動を引き起こすことがある。例えば、Host *でUser deployや特定のIdentityFileが設定されていると、その後に特定のサーバー（例: Host app-01）に対して別のUserやIdentityFileを設定しても、Host *で既に同じオプションが設定されていた場合、後から書かれた設定は無視される可能性がある。

この「Host * Catch-All」の問題を解決するには、一般的な設定やデフォルト値を定義するHost *ブロックを、設定ファイルの末尾に配置することが推奨される。これにより、特定のホストに対する明示的な設定が優先的に適用され、Host *はそれ以外のすべてのホストに対する最終的なフォールバックとして機能する。

また、Includeディレクティブを利用することで、設定ファイルの管理を柔軟に行える。Include config.d/team/*のように記述することで、指定されたディレクトリ内の複数の設定ファイルを読み込むことが可能だ。これにより、チームで共有する共通設定、個人専用設定、そしてグローバルなHost *設定を、それぞれ別のファイルに分けて管理し、読み込む順番を制御できる。例えば、チーム共有設定を最初に読み込み、次に個人の設定、最後にHost *のフォールバック設定を読み込むことで、上書きの優先順位を明確にし、設定衝突を防ぐ。

問題発生時に役立つデバッグコマンドも知っておくと便利だ。 ssh -O check <ホスト名>コマンドは、特定のホストに対してマスター接続が確立され、アクティブになっているかを確認できる。これは、接続多重化が正しく機能しているか判断するのに有効である。 ssh -O exit <ホスト名>は、確立されているマスター接続を意図的に閉じるために使用し、マスター接続の問題をリセットする際に役立つ。 より詳細なデバッグ情報を得るには、ssh -vvv -O check <ホスト名>のように、-vvvオプションを追加する。これは、SSHクライアントがどのような設定を適用しているか、どのような認証を試行しているかといった詳細な処理ログを表示し、問題の原因特定に強力な手がかりとなる。

結論として、SSH接続多重化は非常に強力な機能だが、ProxyJumpを利用した踏み台経由の接続や複数の認証キーを使用する複雑な環境では、制御ソケットのパスを明確に分離すること、認証キーの選択と試行順序を明示的に制御することが重要である。次回、「too many authentication failures」というエラーに遭遇したら、まずはssh -O checkなどのデバッグコマンドを使って、制御ソケットの状態や認証キーの試行状況を確認することが、問題解決への第一歩となるだろう。多くの場合、エラーの原因は制御ソケットの衝突か、認証キーの試行順序にあると覚えておくべきだ。