web-dev-qa-db-ja.com

プライベートEBS AMIからインスタンスを起動した後、「サーバーはキーを拒否しました」

私は自分のEBS AMIを作成し、別のAWSアカウントと共有し、このイメージに基づいて新しいキーペアで新しいインスタンスを起動しました。この新しいインスタンスに接続しようとすると、「Server Refused our key」というエラーが発生します。 。

これは私がやったことです（ステップバイステップ）：

  1. 個人用アカウント（個人用のキーペアを使用）に新しいCentOS 6.3サーバーを構成しました
  2. そのサーバーの作成されたEBS AMIイメージ
  3. この画像をクライアントのアカウントと共有しました
  4. この共有イメージと新しいキーペアに基づいて、クライアントアカウントで新しいインスタンスを起動しました
  5. 新しく起動したインスタンスは、新しいキーペアを取得することを望んでいません。いくつかのテストを行った後、代わりに個人の鍵ペアを受け入れることがわかりました。

イメージから新しいインスタンスを作成して新しいキーペアを受け入れるにはどうすればよいですか？元のイメージの「.ssh/authorized_keys」ファイルを削除して、公開キーなしでこのイメージに基づいて新しいインスタンスを起動しようとしても成功しませんでした。

古いキーペアに添付されない画像の作成方法を教えてください

amazon-ec2amazon-web-servicescentosamazon-amikey-pair
16
Kelvin

私はそのエラーメッセージで同様の問題がありました、そしてここに私がそれを修正した方法があります。これがあなた、またはここで行き詰まり、自分の道をここで見つける誰かを助けることを願っています：

  1. AWSコンソールで、インスタンスが正常に実行されていることを確認します
  2. インスタンスをクリックしたときに表示される正しいパブリックDNSアドレスを使用したことを確認します
  3. 左側から[セキュリティグループ]を選択し、使用するセキュリティグループをクリックします
  4. [受信]タブをクリックします
  5. [新しいルールの作成]ダイアログから[SSH]を選択します
  6. ソースにIPアドレスとCIDR値を入力します。 NATがない場合は、ネットワーク上で32をCIDRとして使用してください（例：？。？。？。？/ 32）
  7. 「ルールの追加」をクリックします
  8. [ルールの変更を適用]をクリックします
  9. インスタンスを右クリックして、[Create Image（EBS AMI）]を選択します。
  10. イメージの作成ウィザードでイメージ名を指定し、[作成]をクリックします。
  11. しばらくしてから、AWSコンソールの左側のナビゲーションバーからAMIを選択します。
  12. 新しいAMIを右クリックし、[インスタンスの起動]をクリックします。
  13. リクエストインスタンスでWizardキーペアを作成する必要があるまで[続行]をクリックします
  14. キーペアを選択してメモします（注：このキーペアの.pemファイルがまだない場合は、左側のナビゲーションバーのキーペアの選択、キーペアの作成などから新しいキーペアを生成する必要があります。 .pemファイルを取得する）
  15. IPアドレス（および32のCIDR-サブネットマスクなし）用に作成したルールを含むセキュリティグループを選択します
  16. [続行]をクリックし、次の画面で[起動]をクリックします
  17. [インスタンス]ビューに戻り、インスタンスが完全に初期化されて正常になるまで待ちます
  18. PuttyGENを開く
  19. ツールバーから[コンバージョン]をクリックし、キーをインポートします
  20. ファイルブラウザで.pemキーに移動して開きます
  21. [パラメーター]ボックスから[SSH-1（RSA）]を選択します
  22. キーペアの名前を[キーコメント]ボックスに入力します（適切なハウスキーピングのため）
  23. [秘密キーの保存]をクリックし、.ppkファイルをファイルシステムのどこかに保存します
  24. PuTTYを開く
  25. [ホスト名]ボックスにEC2インスタンスのパブリックDNSを入力します
  26. ポート22を入力してください
  27. [接続タイプ]ボックスの[SSH]ラジオボタンをチェックします
  28. 左側のナビゲーションバーの接続ツリーからSSHをクリックします。
  29. Authをクリックします
  30. [認証パラメーター]ボックスで[参照]をクリックし、.ppkファイルを開きます
  31. 左側のナビゲーションバーから[セッション]をクリックします。
  32. [保存されたセッション]テキストボックスにこの接続の名前を入力し、[保存]をクリックします（これにより、毎回設定されたPuTTY接続を経由する必要がなく、保存された接続をダブルクリックするだけで済みます-知らない人のために）
  33. 開くをクリックします
  34. ログイン名の入力を求められたら、おそらく「ec2-user」または「ubuntu」を使用します（ヒント：「root」を使用すると、代わりに使用するユーザー名を通知するメッセージが表示されます！）
  35. パスワードは必要ありません。ppkファイルで認証されます
  36. うまくいけば、これでEC-2インスタンスに接続され、準備完了です！
35
Darius

新しいSUSEインスタンスでこの問題が発生しました。ようやく、ユーザー「root」を使用して接続することができました。 ec2-userを拒否し続けました。

13
Pez

これは、ec2インスタンスへのログインに正しいユーザー名を使用していないことを意味します。以下は、PuTTYでec2インスタンスに接続するために使用できるユーザーのリストです。AmazonLinux AMIの場合、ユーザー名はec2-userです。 RHEL5 AMIの場合、ユーザー名はrootまたはec2-userのいずれかです。 Ubuntu AMIの場合、ユーザー名はubuntuです。 Fedora AMIの場合、ユーザー名はFedoraまたはec2-userのいずれかです。 SUSE Linuxの場合、ユーザー名はrootまたはec2-userのいずれかです。それ以外の場合、ec2-userおよびrootが機能しない場合は、AMIプロバイダーに確認してください。

http://docs.aws.Amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html#TroubleshootingInstancesConnectingPuTTY

12
sarabdeep singh

AMIは公式のパブリックAMIではなくコミュニティAMIから発生しているため、インスタンスの起動時にsshキーをコピーするように設定されていないか、別のメカニズムを使用してそれを実行している可能性があります。

私の理解では、起動時にsshキーをコピーするには、 here で簡単に説明したように、一部のシェルスクリプトをインスタンス内で実行する必要があります。

AMIの説明ページ は、「cloud-initが有効になっている」と述べているため、CloudInitを使用して行う方法があるかもしれません。 doc here を参照してください。

3
David Levesque

私はこの問題があり、ec2-userであるはずのときにec2_userと入力していたことがわかりました

1
MikeKulls

デフォルトでは、Amazonは既存のキーに新しいキーを追加します。ドライブを他のアクティブなインスタンスにマウントして解決し、ファイル.ssh/authorized_keysからコンテンツを削除して、新しいキーのPEMキーファイルを追加します。

0
Rama Samy

aWS ubuntu machinのubuntuとしてユーザーを選択することで問題を解決しました。正しいユーザーアカウントとマシンタイプを確認してください。

以下のリンクを参照してください： https://docs.aws.Amazon.com/AWSEC2/latest/UserGuide/PuTTY.html

0
Manish Aman

Server Refused our keyを表示するのは1つの理由にすぎません。

つまり、サーバーのキーペアおよびユーザー名の組み合わせは正しくありません。何度も直面しています。

0
Shiv Singh