DevOpsナレッジハブ
DevOpsナレッジハブ

SSH認証の失敗の診断と解決

SSH認証の失敗に苦労していませんか？この包括的なガイドは、一般的な問題の診断と解決のためのステップバイステップの手順を提供します。接続試行を理解するためにクライアント側の冗長モード（`ssh -vvv`）を効果的に使用する方法を学び、決定的なエラー識別を行うためにサーバー側のログ（`/var/log/auth.log`または`/var/log/secure`）を解釈する方法を学びます。不適切な権限、誤って設定された公開鍵、サーバー設定などの一般的な落とし穴をカバーし、安全なリモートアクセスを迅速かつ効率的に復旧するための実行可能なソリューションを提供します。

39 ビュー

SSH認証失敗の診断と解決

セキュアシェル（SSH）は、セキュアなリモート管理の基盤であり、サーバーやネットワークデバイスへの暗号化されたアクセスを可能にします。しかし、システム管理者や開発者にとって、認証失敗に遭遇することは一般的であり、しばしばフラストレーションを感じる経験です。これらの問題は、単純なタイプミスから複雑なパーミッションの問題、あるいは設定ミスまで、無数の原因に起因する可能性があります。

この記事は、SSH認証失敗を効果的に診断し解決するための包括的なガイドとして機能します。クライアント側の詳細出力とサーバー側のログ分析の重要な役割を強調しながら、体系的なトラブルシューティング方法を深く掘り下げます。これらの診断の手がかりを解釈する方法を理解することで、ほとんどの認証問題の根本原因を特定し、セキュアなリモートアクセスを回復するための知識を身につけることができます。

SSH認証方法の理解

トラブルシューティングに入る前に、SSHが採用する主要な認証方法を理解することが不可欠です。

  • パスワード認証: ユーザーがパスワードを提供し、サーバーがそのパスワードをユーザーデータベースまたは外部認証サービス（PAMなど）と照合して検証します。
  • 公開鍵認証: このよりセキュアな方法は、暗号鍵のペアを使用します。クライアントに保存される秘密鍵と、サーバーに保存される対応する公開鍵です。認証時、クライアントはネットワーク経由で秘密鍵を送信することなく、自身の秘密鍵を使用して身元を証明します。

認証失敗はどちらの方法でも発生する可能性がありますが、トラブルシューティングの手順はしばしば異なります。

初期確認とよくある落とし穴

詳細ログに深く入り込む前に、いくつかの基本的な確認を行うことが賢明です。多くの問題はしばしば単純な見落としであるためです。

  • 正しいユーザー名とホスト名: 正しいユーザー名と、ターゲットサーバーの正確なホスト名またはIPアドレスを使用していることを再確認してください。
  • ネットワーク接続: サーバーに全く到達できますか？ pingを使用して基本的なネットワーク到達可能性を確認します。
    bash ping example.com
  • SSHサービスの状態: ターゲットマシンでSSHサーバー（sshd）が実際に実行されていますか？コンソールアクセスがある場合は、その状態を確認してください。
    bash sudo systemctl status sshd # systemdベースのシステム用（ほとんどのモダンなLinux） sudo service sshd status # 以前のinitシステム用
  • SSHポート: SSHデーモンはデフォルトポート（22）でリッスンしていますか、それともカスタムポートでリッスンしていますか？カスタムポートの場合、-pで指定する必要があります。
  • ファイアウォールルール: ポート22（またはカスタムSSHポート）をブロックしているファイアウォール（クライアント側またはサーバー側）はありますか？ufw、firewalld、またはAWSセキュリティグループなどのサーバーファイアウォールを確認してください。
    bash sudo ufw status sudo firewall-cmd --list-all

クライアント側診断: 詳細モードの活用

SSHクライアントは、接続プロセスと認証試行に関する詳細なデバッグ出力を提供する詳細モード（-v、-vv、-vvv）を提供します。この出力は、クライアントが認証に失敗していると判断する理由を理解するために非常に貴重です。

詳細フラグの使用

  • -v: 詳細出力。
  • -vv: より詳細な出力。
  • -vvv: さらに詳細な出力（認証問題に最も役立つことが多い）。

コマンド例:

ssh -vvv username@your_server_ip

詳細出力の解釈

詳細モードでsshを実行する際、認証プロセスがどこで失敗しているかを示す重要な行を探してください。

  • debug1: Authentications that can continue:: この行は、サーバーが受け入れる認証方法を示します。希望するメソッド（例: publickey）がリストされていない場合、サーバーの設定がそれを妨げています。
    debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
  • debug1: Offering public key:: これは、クライアントが特定の公開鍵を認証に使用しようとしていることを示します。公開鍵認証を期待しているのにこれが表示されない場合、クライアントが鍵を見つけていないか、提供していないことを意味します。
    debug1: Offering public key: /home/user/.ssh/id_rsa RSA SHA256:...
  • debug3: send_pubkey_test: ... trying private key: /home/user/.ssh/id_rsa: クライアントが特定の秘密鍵を使用しようとしていることを確認します。
  • debug1: Server accepts key: ...: これは、クライアントの視点から公開鍵認証が成功したことを示します。これが表示されない場合、鍵はサーバーによって拒否された可能性が高いです。
  • debug1: No more authentication methods to try.: これはPermission deniedエラーの直前に表示されることが多く、クライアントが利用可能なすべての認証方法を試したが成功しなかったことを意味します。
  • debug1: Permission denied (publickey,password).: これは最終的なクライアント側エラーであり、サーバーがすべての試行を拒否したことを要約しています。

ヒント: 提供され、受け入れられた認証方法の順序に細心の注意を払ってください。publickeyが提供された直後にパスワードプロンプトが表示される場合、サーバーが公開鍵を拒否したことを意味することがよくあります。

サーバー側診断: SSHサーバーログの検査

クライアント側の詳細出力はクライアントが何をしようとしているかを示しますが、サーバーログはなぜサーバーが認証試行を拒否したのかについての決定的な情報を提供します。これは、根本原因分析において最も重要なステップであることがよくあります。

SSHサーバーログの場所

SSHサーバーログの場所は、オペレーティングシステムによって異なります。

  • Debian/Ubuntuとその派生版: /var/log/auth.log
  • RHEL/CentOS/Fedoraとその派生版: /var/log/secure
  • Systemdベースのシステム（ほとんどのモダンなLinux）: journalctlも使用できます。

サーバーログの表示とフィルタリング

tailやjournalctlなどのツールを使用して、ログをリアルタイムで監視したり、SSH固有のエントリをフィルタリングしたりできます。

コマンド例:

# Debian/Ubuntu用
sudo tail -f /var/log/auth.log | grep sshd

# RHEL/CentOS用
sudo tail -f /var/log/secure | grep sshd

# systemdベースのシステム用（現在のログを表示する最も堅牢な方法）
sudo journalctl -u sshd -f

# 最初からすべてのsshdログを表示する（失敗が以前に発生した場合に有用）
sudo journalctl -u sshd

一般的なサーバーログエントリとその意味

接続を試行する際に、sshdに関連するメッセージを探してください。認証失敗を示す一般的なエントリをいくつか示します。

  • Failed password for user from IP port ssh2: パスワード認証の試行が失敗したことを示します。これはパスワードの誤り、またはユーザーがパスワード経由でのログインを許可されていないためである可能性があります。
  • Authentication refused: bad ownership or modes for directory /home/user/.ssh: これは非常によくある公開鍵認証エラーです。サーバー上の.sshディレクトリのパーミッションが間違っています。
    • 解決策: chmod 700 /home/user/.ssh
  • Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys: もう一つの一般的な公開鍵エラーで、authorized_keysファイルのパーミッションが間違っていることを示します。
    • 解決策: chmod 600 /home/user/.ssh/authorized_keys
  • sshd[PID]: error: Permissions 0777 for '/home/user/.ssh/authorized_keys' are too open.: 過度に緩いファイルモードの問題を明示的に示しています。SSHはセキュリティ上の理由からパーミッションに非常に厳格です。
  • User username from IP not allowed because not listed in AllowUsers: /etc/ssh/sshd_configのAllowUsersディレクティブに従って、ユーザーがSSH経由でのログインを許可されていません。
  • User username from IP not allowed because listed in DenyUsers: DenyUsersによってユーザーがSSHアクセスを明示的に拒否されています。
  • input_userauth_request: invalid user username: 提供されたユーザー名がサーバーに存在しません。
  • Publickey authentication refused: authenticate using identity file.: これは通常、クライアントが提示した公開鍵が、そのユーザーのサーバーのauthorized_keysファイル内のどの鍵とも一致しないか、鍵の形式が正しくないことを意味します。
  • Maximum authentication attempts exceeded for user from IP: クライアントが認証方法を試行しすぎたか、誤った資格情報を送信しすぎました。sshd_configのMaxAuthTriesによって制御されます。
  • Connection closed by authenticating user IP port 22 [preauth]: これは、受け入れ可能な認証方法が見つからなかった場合、または失敗後にクライアントが接続を突然閉じた場合に発生する可能性があります。

一般的な認証失敗のシナリオと解決策

一般的な失敗を分類し、その具体的な解決策を見ていきましょう。

1. パスワード認証の失敗

  • パスワードの誤り: 最も直接的な問題です。パスワードを再確認してください。キーボードレイアウト、Caps Lock、Num Lockに注意してください。
  • ユーザーが許可されていない: sshd_configファイル（/etc/ssh/sshd_config）が特定のユーザーのログインを制限している可能性があります。
    • PermitRootLogin no: rootログインを防止します（セキュリティのため強く推奨されます）。
    • AllowUsers username1 username2: 指定されたユーザーのみがログインできます。
    • DenyUsers username: 指定されたユーザーはログインできません。
    • AllowGroups groupname: 指定されたグループのユーザーのみがログインできます。
    • 解決策: sshd_configディレクティブを調整し、sshdを再起動します。
  • PAMの問題: サーバーがPluggable Authentication Modules（PAM）を使用している場合、PAM設定の問題がパスワード認証を妨げる可能性があります。PAM固有のエラーについては/var/log/auth.logを確認してください。これは基本的なSSH設定ではあまり一般的ではありません。

2. 公開鍵認証の失敗

公開鍵認証はより安全であることが多いですが、設定関連のエラーが発生しやすいです。

  • ファイル/ディレクトリのパーミッションの誤り（サーバー側）: これが最も一般的な原因です。SSHはセキュリティのために~/.sshと~/.ssh/authorized_keysに厳格なパーミッションを要求します。
    • ~: ユーザーのホームディレクトリはワールド書き込み可能であってはなりません（chmod 755 ~は通常安全です）。
    • ~/.ssh: 700でなければなりません（所有者のみがrwx）。
      bash chmod 700 ~/.ssh
    • ~/.ssh/authorized_keys: 600でなければなりません（所有者のみがrw）。
      bash chmod 600 ~/.ssh/authorized_keys
    • これらのファイルとディレクトリの所有者は、ログインを試行しているユーザーでなければなりません。
      bash sudo chown -R username:username ~/.ssh
  • authorized_keysの内容の誤り: ~/.ssh/authorized_keys内の公開鍵が破損している、余分な文字が含まれている、または形式が誤っている可能性があります。各鍵は1行に記述する必要があります。適切な形式を確保する簡単な方法は、クライアントからssh-copy-idを使用することです。
    bash ssh-copy-id -i ~/.ssh/id_rsa.pub username@your_server_ip
    クライアント側で公開鍵のフィンガープリントを確認するには: ssh-keygen -l -f ~/.ssh/id_rsa.pub
  • クライアントが鍵を提供しない: 秘密鍵がデフォルトの場所（~/.ssh/id_rsa）にないか、ssh-agentにロードされていないか、-iで指定していない可能性があります。
    • 解決策: 秘密鍵が~/.ssh内のid_rsa（またはid_ed25519など）であり、600のパーミッションを持っていることを確認します。そうでない場合は、次のように指定します。
      bash ssh -i /path/to/your/private_key username@your_server_ip
    • ssh-agentを使用している場合、鍵が追加されていることを確認します。
      bash eval "$(ssh-agent -s)" ssh-add ~/.ssh/your_private_key
  • sshd_configが公開鍵認証を許可しない: サーバーのSSHデーモンが公開鍵認証を許可しないように設定されている可能性があります。
    • /etc/ssh/sshd_configでPubkeyAuthentication yesを確認します。
    • AuthorizedKeysFile .ssh/authorized_keysが正しいファイルを指していることを確認します。デフォルトは通常問題ありません。
    • 解決策: PubkeyAuthentication yesを設定し、sshdを再起動します。
  • SELinux/AppArmorの干渉: SELinuxやAppArmorを使用しているシステムでは、これらのセキュリティモジュールが、ファイルパーミッションが正しくてもSSHがユーザーのホームディレクトリや.sshファイルにアクセスするのをブロックすることがあります。手がかりについては、監査ログ（/var/log/audit/audit.logまたはsudo ausearch -m AVC -ts recent）を確認してください。これは高度なシナリオです。

3. 接続拒否またはタイムアウト

これらは厳密には「認証」の失敗ではありませんが、認証試行が開始される前に発生し、それを妨げます。

  • ファイアウォールのブロック: クライアント（例: ローカルOSファイアウォール）とサーバー（例: ufw、firewalld、クラウドセキュリティグループ、ネットワークACL）の両方のファイアウォールを確認します。ポート22（またはカスタムポート）が開いていることを確認してください。
  • SSHサーバーが実行されていない: sshdサービスがアクティブでないか、クラッシュしている可能性があります。
  • ポート/IPの誤り: 誤ったポートまたはIPアドレスに接続しようとしている。

一般的なデバッグのヒント

  • sshd_configの確認: サーバー上の/etc/ssh/sshd_configを常に確認し、干渉する可能性のある非デフォルト設定がないか確認してください。変更を加えた後は、常にSSHデーモンを再起動してください: sudo systemctl restart sshd（またはsudo service sshd restart）。
  • 新しいユーザー/鍵でテスト: 可能であれば、新しいユーザーと新しい公開鍵/秘密鍵のペアを作成します。この新しい設定で認証を試してみてください。うまくいけば、問題は元のユーザーの設定に固有のものです。
  • 問題を隔離する: 別のクライアントマシンから接続を試してみてください。うまくいけば、問題はクライアント固有のものです。複数のクライアントから失敗する場合は、問題はサーバー固有のものです。
  • LogLevelの引き上げ（サーバー側）: 詳細なデバッグのために、一時的に/etc/ssh/sshd_configでLogLevel DEBUGを設定し、sshdを再起動することができます。デバッグログは非常に詳細になりディスク容量を消費する可能性があるため、トラブルシューティング後にこの設定を元に戻すことを忘れないでください。

結論

SSH認証失敗の診断には、クライアント側の詳細出力とサーバー側のログ分析を組み合わせた体系的なアプローチが必要です。ssh -vvvとSSHデーモンのログ（auth.logまたはsecure）が提供する手がかりを綿密に調べることで、間違ったパスワード、設定ミスの公開鍵、厳格なファイルパーミッション、またはサーバー側の設定など、障害の正確なポイントを効果的に特定できます。

簡単な確認から始め、次にクライアント側の詳細出力に移り、最後にサーバーログからの決定的な洞察を活用することを忘れないでください。これらの技術を駆使すれば、最も複雑なSSH認証の問題さえも解決し、リモートシステムへのセキュアなアクセスを維持するための十分な準備が整うでしょう。