DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ

SSH認証エラーの診断と解決

SSH認証エラーを解決するための詳細なクライアントログ、サーバーログ、権限チェック、鍵の検証、sshd設定の修正方法を解説します。

SSH認証エラーの診断と解決

Secure Shell（SSH）は、安全なリモート管理の基盤であり、サーバーやネットワークデバイスへの暗号化されたアクセスを可能にします。しかし、認証エラーに遭遇することは、システム管理者や開発者にとって一般的でしばしばフラストレーションのたまる経験です。これらの問題は、単純なタイプミスから複雑な権限問題や設定ミスまで、さまざまな原因から発生します。

この記事は、SSH認証エラーを効果的に診断し解決するための包括的なガイドです。クライアント側の詳細出力とサーバー側のログ分析の重要な役割に焦点を当て、体系的なトラブルシューティング方法を詳しく説明します。これらの診断手がかりを解釈する方法を理解することで、ほとんどの認証問題の根本原因を特定し、安全なリモートアクセスを復旧できるようになります。

SSH認証方式の理解

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

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

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

初期チェックとよくある落とし穴

詳細ログを確認する前に、基本的なチェックを行うことが賢明です。多くの問題は単純な見落としであることが多いからです。

  • 正しいユーザー名とホスト名: 正しいユーザー名と、対象サーバーの正確なホスト名またはIPアドレスを使用していることを再確認してください。
  • ネットワーク接続: サーバーに到達できますか？ nc -vz host 22 または ssh -vvv を使用してSSHの到達可能性をテストします。ping も役立ちますが、多くのサーバーはSSHが動作していてもICMPをブロックします。
    ping example.com
  • SSHサービスの状態: 対象マシンでSSHサーバー（sshd）が実際に実行されていますか？ コンソールアクセスがある場合は、その状態を確認してください。
    sudo systemctl status sshd # systemdベースのシステム（最新のLinuxのほとんど）
sudo service sshd status    # 古いinitシステムの場合
  • SSHポート: SSHデーモンはデフォルトポート（22）でリッスンしていますか、それともカスタムポートですか？ カスタムポートの場合は、-p で指定する必要があります。
  • ファイアウォールルール: ポート22（またはカスタムSSHポート）をブロックしているファイアウォール（クライアント側またはサーバー側）はありますか？ ufw、firewalld、AWSセキュリティグループなどのサーバーファイアウォールを確認してください。
    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: 提供されたユーザー名がサーバーに存在しません。
  • Failed publickey for user または、提供された鍵が繰り返された後にパスワードが続く場合: クライアントが提示した公開鍵がそのユーザーの受け入れられた鍵と一致しないか、サーバーがパーミッションまたはポリシーにより鍵を拒否しました。
  • 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）である必要があります。
      chmod 700 ~/.ssh
    • ~/.ssh/authorized_keys: 600（所有者のみrw）である必要があります。
      chmod 600 ~/.ssh/authorized_keys
    • これらのファイルとディレクトリの所有者は、ログインしようとしているユーザーである必要があります。
      sudo chown -R username:username ~/.ssh
  • authorized_keys の内容の誤り: ~/.ssh/authorized_keys 内の公開鍵が破損している、余分な文字がある、または不正な形式である可能性があります。各鍵は1行である必要があります。適切な形式を確保する簡単な方法は、クライアントから ssh-copy-id を使用することです。
    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 であることを確認してください。そうでない場合は、指定します。
      ssh -i /path/to/your/private_key username@your_server_ip
    • ssh-agent を使用している場合、鍵が追加されていることを確認してください。
      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 -vvv を使用してクライアントが何を提供しているかを確認し、サーバーログをチェックして sshd がそれを拒否した理由を学びましょう。ほとんどの公開鍵の失敗は、鍵の誤り、authorized_keys エントリの欠落、厳格なファイルパーミッション、またはユーザーや方式をブロックする sshd_config ルールに起因します。