アクセス権に関する問題のトラブルシューティング

このページでは、Bare Metal Solution のアクセスに関する問題のトラブルシューティングに関するヒントを示します。

既知の問題と制限事項のページで、質問や問題がすでに解決されていないかを確認してください。

SSH クライアントが接続できない

SSH クライアントがサーバーに接続できない場合は、次のいずれかのエラーが表示されることがあります。

• connection timeout または connection refused: SSH クライアントが接続できません。

• Permission denied (publickey): SSH クライアントが認証に失敗しました。

失敗した SSH 接続を診断する手順は次のとおりです。

1. 接続をテストします。

   ping コマンド、traceroute コマンド、nc コマンドを使用してホストに到達可能で、SSH ポート（22）が開いていることを確認します。

   ping SERVER_NAME
   

   traceroute SERVER_NAME
   

   echo "" | nc SERVER_NAME 22
   

   それでも問題が解決しない場合は、問題は SSH ではなくネットワーク層にある可能性があります。

2. クライアント側のデバッグ出力を調べます。

   1. SSH プロトコルの詳細設定を有効にします。

      ssh -v SERVER_NAME -i ~/.ssh/id_ecdsa
      

      このコマンドは、クライアント側の SSH プロトコルの主要なイベントを示すデバッグ情報を出力します。

      次の出力例は、クライアントがキーを送信したものの、サーバーが拒否したことを示しています。サーバーは別の公開鍵で認証を続行するよう要求しましたが、クライアントには追加の公開鍵がありません。

      .. .. ..
      debug1: Server host key: ecdsa-sha2-nistp256 SHA256:V9cRYdqcAJv+RPfN+oofNTVdUxs6VlocP4uMWOxeGKI
      debug1: Host 'bms-server' is known and matches the ECDSA host key.
      debug1: Found key in /root/.ssh/known_hosts:1
      debug1: rekey after 134217728 blocks
      debug1: SSH2_MSG_NEWKEYS sent
      debug1: expecting SSH2_MSG_NEWKEYS
      debug1: SSH2_MSG_NEWKEYS received
      debug1: rekey after 134217728 blocks
      debug1: SSH2_MSG_EXT_INFO received
      debug1: kex_input_ext_info: server-sig-algs=
      debug1: SSH2_MSG_SERVICE_ACCEPT received
      debug1: Authentications that can continue: publickey
      debug1: Next authentication method: publickey
      debug1: Offering ECDSA public key: /root/.ssh/id_ecdsa
      debug1: Authentications that can continue: publickey
      debug1: No more authentication methods to try.
      Permission denied (publickey).
      

   2. SSH 詳細出力にエラー メッセージの原因が明確に示されていない場合は、strace コマンドを実行します。

      strace ssh SERVER_NAME -i ~/.ssh/id_ecdsa > strace-ssh.txt 2>&1
      

   3. strace の出力を調べて、コアの問題に関連するエラーがないか確認します。

      場合によっては、クライアント側のデバッグ出力が問題を特定するのに十分でない場合があります。サーバー側のトレースを実行してエラーを見つける必要が生じる場合もあります。サーバーに SSH 接続できなくなるまでは、インタラクティブ シリアル コンソールを使用して、次の手順を実行してください。

3. サーバー側のデバッグ出力を調べます。

   1. 現在の SSH 設定を見つけます。

      grep -v "^#" /etc/ssh/sshd_config | grep -v "^$"
      

   2. SSH の詳細情報を取得するために、/etc/ssh/sshd_config ファイルで次のパラメータを設定します。

      SyslogFacility AUTH
      LogLevel DEBUG
      

   3. サービスを再起動して変更を適用します。

      service sshd restart
      

   4. クライアント側で ssh コマンドを実行して、ログから sshd 関連のメッセージを抽出します。

      grep sshd /var/log/messages
      

      または、次のコマンドを使用して、特定の期間の該当メッセージをすべてエクスポートすることもできます。

      journalctl -u sshd -S "START_TIME" -U "END_TIME" --utc
      

      以下を置き換えます。

      • START_TIME: 期間の開始日時（形式: yyyy-mm-dd hh:mm:ss）。
      • END_TIME: 期間の終了日時（形式: yyyy-mm-dd hh:mm:ss）。

      例:

      journalctl -u sshd -S "2023-04-25 18:38:00" -U "2023-04-25 18:40:00" --utc
      

これらの問題を解決するには、次の手順を検討してください。

• クライアントの鍵ファイルに読み取り専用権限（フラグ 400）が設定されていることを確認します。それ以外の場合、SSH クライアントは受け入れません。

  使用中の秘密鍵の読み取り専用フラグを設定するには、次のコマンドを実行します。

  chmod 400 ~/.ssh/id_ed25519
  

• サーバー側で、対応するユーザーのローカル構成ファイル（~/.ssh/authorized_keys）にクライアントの公開鍵が指定されているかどうかを確認します。

• 場合によっては、問題が SSH プロトコルのバージョンや SSH のアルゴリズムに関連している可能性があります。サーバー側とクライアント側のデバッグ出力で、このような問題が示される場合があります。通常、ssh と sshd_config の man ページには、必要な構成の維持に関する詳細情報が記載されています。たとえば、サポートされている鍵交換アルゴリズムや暗号を確認するには、次のコマンドを使用します。

  # Find key exchange algorithms
  ssh -Q kex
  # Find the symmetric encryption ciphers
  ssh -Q cipher