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

Simple Application Server:root ユーザーの SSH ログインにおける「Permission denied, please try again」エラーの解決策

最終更新日:Jun 04, 2026

問題の説明

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

問題の診断

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

    1. Simple Application Server コンソールに移動します。上部メニューで、対象のリージョンとリソースグループを選択します。

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

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

    PermitRootLogin または PasswordAuthenticationno に設定されている場合は、「root での SSH ログインに関する "Permission denied, please try again" エラーを解決する」を参照して問題を解決してください。

    • PermitRootLogin: no に設定すると、root SSH ログインをブロックします。

    • PasswordAuthentication: no に設定すると、すべてのユーザーのパスワードログインが無効になります。

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

    SELinux がログイン試行をブロックし、システムセキュリティログにエラーを記録することがあります。

    SELinux は、各プロセスがアクセスできるものを管理する強制アクセス制御 (MAC) ルールを適用します。
    # 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 ポリシーが原因であると考えられます。「root SSH ログインでの「Permission denied, please try again」を解決する」をご参照ください。

解決策

ユースケース 1:SSH 設定によるログオン拒否

  1. 設定の変更

    sudo vi /etc/ssh/sshd_config

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

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

    • root ユーザーのログオン許可

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

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

        重要

        パスワードを使用した root でのログオン (PermitRootLogin yes) を許可すると、インスタンスがブルートフォース攻撃にさらされるリスクが高まります。代わりに、キーベースの認証を使用するか、ソース 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 statusenabledCurrent 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 を使用してインスタンスに接続し、接続できることを確認します。