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

所要時間3分
0

SSH で自身の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスに接続すると、「サーバーがキーを拒否しました」というエラーが表示されます。

簡単な説明

SSH サーバー (sshd) でプライベート SSH キーを拒否される理由は複数あります。このエラーが表示される一般的な理由は次のとおりです:

解決策

あなたの EC2 インスタンスに接続する際に使用したあなたの AMI のユーザー名が正しくありません

有効なユーザー名のリストについては、「 エラー: サーバーはキーを拒否した、または利用可能なサポートされる認証方法はありません」を参照してください。

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

インスタンスにアクセスしようとしたユーザーがサーバーから削除された場合は、そのユーザーを新規ユーザーとして追加します。詳細については、「Amazon EC2 Linux インスタンスに SSH アクセスを持つ新しいユーザーアカウントを追加する方法を教えてください」を参照してください。

インスタンスにアクセス権限の問題があるか、ディレクトリがありません

インスタンスの権限とディレクトリを確認するには、次の 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 エージェント のインストールが必要です。セッションマネージャーの詳細と前提条件の一覧については、「Setting up Session Manager」を参照してください。

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

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

3.    stat コマンドで、ホームディレクトリにあるファイルの権限が正しいことを確認します。正しい権限のリストを以下に示します:

  • 例えば、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 マシンに接続するときにリモート接続エラーの原因となるいくつかの問題が確認されて修正されます。詳細については、「SSH を使用して EC2 インスタンスに接続しようとするとエラーが発生します。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 モジュールの詳細については、Cloud-init ドキュメントの「SSH - Configure SSH and SSH keys」を参照してください。

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

2.    [インスタンスの状態] を選択し、**[インスタンスの停止]**を選択します。

注:****[停止] が使用できない場合は、インスタンスがすでに停止しているか、そのルートデバイスがインスタンスストアボリュームであるかのどちらかです。

3.    [アクション][インスタンス設定]、**[ユーザーデータの編集]**の順に選択します。

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

**注:**次のスクリプトでは、ec2-user というユーザー名を使用しています。ec2-userあなたの AMI のユーザー名に変更してください。

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 ポリシーを使用してください。

関連情報

PuTTY で Windows から Linux インスタンスに接続する

Amazon EC2 キーペアと Windows インスタンス

SSH を使用して Amazon EC2 Linux インスタンスに接続できないのはなぜですか?

AWS公式
AWS公式更新しました 1年前
コメントはありません

関連するコンテンツ