SSH を使用して EC2 インスタンスに接続しようとすると、「サーバーはキーを拒否しました」というエラーが表示されるのはなぜですか?

最終更新日: 2021 年 4 月 26 日

SSH を使用して Amazon Elastic Compute Cloud (Amazon EC2) インスタンスに接続すると、「サーバーはキーを拒否しました」というエラーが表示されます。どうすれば解決できますか?

簡単な説明

SSH サーバー (sshd) がプライベート SSH キーを拒否することには、いくつかの理由があります。このエラーが発生する一般的な原因を次に示します。

解決方法

EC2 インスタンスに接続するときに、AMI に使用しているユーザー名に間違いがある

インスタンスにアクセスしようとしているユーザーがサーバーから削除されたか、アカウントがロックされた

インスタンスへのアクセスを試みているユーザーがサーバーから削除されている場合、ユーザーを新しいユーザーとして追加しなおします。詳細については、SSH アクセスを行える新しいユーザーアカウントを Amazon EC2 Linux インスタンスに追加するには? を参照してください。

インスタンスにアクセス権限の問題があるか、またはディレクトリが見つからない

次の 4 つの方法のうち、いずれかの方法を使用して、インスタンスのアクセス権限とディレクトリを検証できます。

方法 1: EC2 シリアルコンソールを使用する

Linux 用 EC2 シリアルコンソールを有効にしている場合は、それを使用して、サポートされている Nitro ベースのインスタンスタイプのトラブルシューティングを行うことができます。シリアルコンソールは、起動の問題、ネットワーク設定、および SSH 設定の問題のトラブルシューティングに役立ちます。シリアルコンソールは、正常に動作するネットワーク接続を必要とすることなく、インスタンスに接続します。Amazon EC2 コンソールまたは AWS コマンドラインインターフェイス (AWS CLI) を使用して、シリアルコンソールにアクセスできます。

シリアルコンソールを使用する前に、アカウントレベルでコンソールにアクセス権を付与する必要があります。その後、IAM ユーザーにアクセス権を付与する AWS Identity and Access Management (IAM) ポリシーを作成する必要があります。また、シリアルコンソールを使用するすべてのインスタンスには、パスワードベースのユーザーを 1 つ以上含める必要があります。インスタンスが到達不能で、シリアルコンソールへのアクセスを設定していない場合は、方法 2、3、または 4 の手順に従います。Linux 用 EC2 シリアルコンソールの設定の詳細については、EC2 シリアルコンソールへのアクセスを設定するをご参照ください。

方法 2: AWS Systems Manager Session Manager を使用してインスタンスにログインし、アクセス権限を確認する

注: この方法を使用するには、SSM エージェントをインストールする必要があります。Session Manager の詳細と前提条件の一覧については、Session Manager の開始方法をご参照ください。

1.    AWS Systems Manager コンソールを開きます。

2.    セッションを開始します

3.    stat コマンドを使用して、home ディレクトリにあるファイルのアクセス許可が正しいことを確認します。以下に、正しいアクセス許可のリストを示します。

  • Linux ホームディレクトリ (/home) であれば、(0755/drwxr-xr-x) にする必要があります。
  • ユーザーのホームディレクトリ (/home/ec2-user/) であれば、(0700/drwx------) にする必要があります。
  • .ssh ディレクトリのアクセス許可 (/home/ec2-user/.ssh) であれば、(0700/drwx------) にする必要があります。
  • authorized_keys ファイルのアクセス許可 (/home/ec2-user/.ssh/authorized_keys) であれば、(0600/-rw-------) にする必要があります。

stat コマンドと結果の出力の例を、以下に示します。この例では、ec2-user がユーザー名です。AMI に従ってユーザー名を変更します。

$ stat /home/ec2-user/
  File: '/home/ec2-user/'
  Size: 4096      	Blocks: 8          IO Block: 4096   directory
Device: 10301h/66305d	Inode: 18322       Links: 3
Access: (0700/drwx------)  Uid: (  500/ec2-user)   Gid: (  500/ec2-user)

4.    アクセス許可が前述の値と一致しない場合は、次のコマンドを実行します。

$ sudo chown root:root /home
$ sudo chmod 755 /home
$ sudo chown ec2-user:ec2-user /home/ec2-user -R
$ sudo chmod 700 /home/ec2-user /home/ec2-user/.ssh
$ sudo chmod 600 /home/ec2-user/.ssh/authorized_keys

5.    セッションを終了します。

6.    インスタンスに SSH 接続します。

方法 3: AWSSupport-TroubleshootSSH ドキュメントを実行して、エラーの原因となる問題を自動的に修正する

AWSSupport-TroubleshootSSH オートメーションドキュメントは、Amazon EC2Rescue ツールをインスタンスにインストールし、SSH 経由で Linux マシンに接続する際にリモート接続エラーを引き起こす問題を確認し修正します。詳細については、AWSSupport-TroubleshootSSH オートメーションのワークフローを使用して、SSH 接続の問題をトラブルシューティングする方法を教えてくださいをご参照ください。

方法 4: ユーザーデータを使用してインスタンスのアクセス権限を修正する

重要な点:

  • この復旧手順では、インスタンスを停止してから再起動する必要があります。これを行うと、インスタンスストアボリューム上のデータは失われます。詳細については、インスタンスのルートデバイスタイプの判別をご参照ください。
  • インスタンスが Amazon EC2 Auto Scaling グループの一部である場合、インスタンスを停止すると終了する可能性があります。これは、Amazon EMR、AWS CloudFormation、AWS Elastic Beanstalk など、AWS Auto Scaling を使用するサービスによって起動されるインスタンスでも発生する可能性があります。このシナリオでインスタンスが削除されるかどうかは、Auto Scaling グループのインスタンススケールイン保護の設定によって異なります。インスタンスが Auto Scaling グループの一部である場合は、解決手順を開始する前に、一時的に Auto Scaling グループからインスタンスを削除してください。
  • インスタンスを停止および再起動すると、インスタンスのパブリック IP アドレスが変更されます。インスタンスに外部トラフィックをルーティングする際のベストプラクティスは、パブリック IP アドレスではなく Elastic IP アドレスを使用することです。
  • インスタンスのルートデバイスがインスタンスストアボリュームである場合、ユーザーデータを使用して SSH キーを変更することはできません。詳細については、インスタンスのルートデバイスタイプの判別をご参照ください。
  • インスタンスのユーザーデータの更新は、cloud-init ディレクティブをサポートするすべてのディストリビューションに適用されます。これらの手順を正常に実行するには、cloud-init をインストールして設定する必要があります。cloud-init SSH モジュールの詳細については、SSH - SSH および SSH キーを構成するを参照してください。

1.    Amazon EC2 コンソールを開き、インスタンスを選択します。

2.    [Instance State (インスタンスの状態)]、[Stop instance (インスタンスの停止)] の順に選択します。

注: [Stop (停止)] が無効になっている場合は、インスタンスがすでに停止しているか、そのルートデバイスがインスタンスストアボリュームになっています。

3.    [Actions (アクション)]、[Instance Settings (インスタンスの設定)]、[Edit User Data (ユーザーデータの編集)] の順に選択します。

4.    次のスクリプトを [ユーザーデータ] フィールドにコピーし、[保存] を選択します。スクリプト全体をコピーしてください。余分なスペースを追加しないでください。

注意: 次のスクリプトでは、ユーザー名に ec2-user を使用します。ec2-userAMI のユーザー名に変更します。

Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0

--//
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"

#cloud-config
cloud_final_modules:
- [scripts-user, always]

--//
Content-Type: text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="userdata.txt"

#!/bin/bash
chown root:root /home
chmod 755 /home
chown ec2-user:ec2-user /home/ec2-user -R
chmod 700 /home/ec2-user /home/ec2-user/.ssh
chmod 600 /home/ec2-user/.ssh/authorized_keys
--//

5.    インスタンスを起動し、インスタンスに SSH 接続します。

注意: デフォルトでは、ユーザーデータスクリプトはインスタンスごとに 1 回実行されます。この手順でデフォルトの動作を変更すると、インスタンスの再起動、停止、起動を実行するごとにパブリックキーが追加されます。デフォルトの動作を復元するには、カスタムユーザーデータを削除します。ベストプラクティスとして、セキュリティへの影響を考慮し、インスタンスの初回起動後にユーザーデータが実行されるようにすることをお勧めします。ModifyInstanceAttribute API メソッドを使用して、インスタンスのユーザーデータを変更できます。このメソッドへのアクセスを制限するには、IAM ポリシーを使用します。