すべてのプロダクト
Search
ドキュメントセンター

:Linux インスタンスへの SSH 接続における「Permission denied,please try again」エラーの解決

最終更新日:Oct 25, 2025

問題の説明

SSH を使用して Linux インスタンスに接続すると、正しいユーザー名とパスワードを使用しても、Permission denied, please try again というメッセージが表示されて接続に失敗します。

問題の診断

  1. VNC 接続を使用して ECS インスタンスにログインします。

    1. ECS コンソール - インスタンス に移動します。上部のナビゲーションバーで、対象のリージョンとリソースグループを選択します。

    2. 対象インスタンスの詳細ページに移動します。[接続] をクリックし、[VNC] を選択します。ユーザー名とパスワードを入力して ECS インスタンスにログインします。

  2. SSH サービスの設定を確認します。

    設定で PermitRootLogin または PasswordAuthentication パラメーターが no に設定されている場合は、「ユースケース 1: 設定で SSH ログインが無効になっている」をご参照ください。

    • PermitRootLogin: このパラメーターを "no" に設定すると、root ユーザーが SSH 経由でログインすることが禁止されます。

    • PasswordAuthentication: このパラメーターを "no" に設定すると、すべてのユーザーがパスワード認証でログインすることが禁止されます。

    sudo cat /etc/ssh/sshd_config
  3. システムのセキュリティログを確認します。

    SELinux ポリシーがログイン試行をブロックすると、セキュリティログにエラーが記録されます。

    SELinux ポリシーは、プロセスがファイル、ポート、またはその他のリソースに対して実行できる操作を定義する、強制アクセス制御ルールのセットです。
    # CentOS/RHEL システムの場合
    sudo grep -iE --color=auto 'Could not get shadow information' /var/log/secure
    
    # Debian/Ubuntu システムの場合
    sudo grep -iE --color=auto 'Could not get shadow information' /var/log/auth.log

    これらのコマンドが出力を返さない場合、SELinux ポリシーが原因である可能性が高いです。この場合は、「ユースケース 2: SELinux ポリシーによってログインがブロックされる」をご参照ください。

問題の解決

ユースケース 1: 設定で SSH ログインが無効になっている

  1. 設定の変更

    sudo vi /etc/ssh/sshd_config

    必要に応じてパラメーターを調整します:

    • パスワード認証を許可する: PasswordAuthentication noPasswordAuthentication yes に変更します。

    • root ユーザーのログインを許可する:

      • キーベースの認証を許可する (推奨): root ログインにキーペアを使用するには、PermitRootLoginprohibit-password に設定します。

      • パスワード認証を許可する: PermitRootLogin noPermitRootLogin yes に変更します。

        重要

        パスワード (PermitRootLogin yes) を使用した root ログインを許可すると、インスタンスがブルートフォース攻撃にさらされるリスクが高まります。代わりに、キーベースの認証を使用するか、「ソース IP アドレスによるアクセスを制限する」をご参照ください。

    ファイルを変更した後、Esc を押し、:wq と入力して Enter を押してファイルを保存し、終了します。

  2. 設定の確認とサービスの再起動

    1. 設定ファイルの構文を確認します。出力がない場合は、構文が正しいことを示します。

      sudo sshd -t
    2. SSH サービスを再起動して変更を適用します。

      sudo systemctl restart sshd
  3. 接続の確認

    SSH を使用してインスタンスに再度接続し、問題が解決したことを確認します。

ユースケース 2: SELinux ポリシーによってログインがブロックされる

  1. SELinux の現在のステータスを確認する

    SELinux が enforcing モードであるかどうかを確認します。

    sudo sestatus

    出力に SELinux statusenabled と表示され、Current modeenforcing と表示されている場合、SELinux ポリシーはアクティブです。

  2. SELinux モードを一時的に変更してアクセスを復元する

    SELinux を一時的に Permissive モードに切り替えます。このモードでは、SELinux は警告をログに記録しますが、操作をブロックしません。

    sudo setenforce 0
    重要

    この変更は一時的なものであり、インスタンスが再起動するとリセットされます。

    コマンドを実行した後、SSH を使用して再度ログインを試みます。ログインに成功すると、SELinux が問題の原因であったことが確認されます。

  3. SELinux 設定を永続的に変更する (オプション)

    1. 設定ファイルを変更します。SELinux のデフォルトモードを enforcing から permissive に変更します。

      sudo sed -i 's/SELINUX=enforcing/SELINUX=permissive/' /etc/selinux/config
    2. インスタンスを再起動して変更を適用します。

  4. 接続の確認

    SSH を使用してインスタンスに再度接続し、問題が解決したことを確認します。