web-dev-qa-db-ja.com

Amazon EC2のアクセス許可が拒否されました(公開キー)

これは一般的な問題のようですが、私の特定のケースは少し異なっているようです。

コマンドラインツールを使用して新しいAmazon EC2インスタンスをセットアップし、SSHを介して接続し、構成作業を行いました。

ただし、最初はインスタンスにsshできませんでした。インスタンスを停止して再起動する必要があり、その後接続できました。再起動する前に、応答がありました。

Permission denied (publickey).

それは昨夜でした、今朝、私は同じインスタンスに戻り、今私が得るすべては

Permission denied (publickey).

喜びなくインスタンスを再起動しようとしました。

誰かが私をここで正しい方向に向けることができますか?昨夜機能したのと同じコマンドは機能しなくなりました。MacbookProから接続しています。

72
Trevor

他の誰かが同じことを見た場合に備えて、私は自分の質問に答えるつもりです...昨夜私はやった:

ssh-add ~/.ssh/[keypair name]

次に接続しています:

ssh ec2-user@[ec2 instance ip]

今朝、私は同じことを試みたが、接続できなかった。しかし、やって

ssh -i ~/.ssh/[keypair name] ec2-user@[ec2 instance ip]

私を迎え入れます。

キーペアでssh-addを使用すると、再び取得されます。ssh-addは、発行したシェル内でのみ機能すると推測しています。端末ウィンドウを閉じて別のウィンドウを開いたとき、明示的でなくても使用可能なキーペア。

75
Trevor

これは、正しいユーザー名を使用していなかったために起こっていました。チュートリアルで使用したAMIを使用しているときにログインできましたが、別のAMI(ubuntu + BitnamiのLAMP)を使用しようとすると、Permission denied (public key).エラーが発生しました。チュートリアルAMIのユーザー名をubuntuからec2-userに変更すると、同じエラーが発生することがわかりました。

したがって、簡単なグーグルは、Bitnami AMIのユーザー名がbitnamiであることを示しています。問題が解決しました。

28
RyanM

同様の問題にぶつかり、ホームフォルダーに対するアクセス許可であることが判明しました。ありがたいことに、私はまだ別の既存のssh接続を開いていたので、ec2インスタンスのログを確認できました。

$ Sudo less/var/log/secure

含まれるもの:

Dec  9 05:58:20 ... sshd[29816]: Authentication refused: 
    bad ownership or modes for directory /home/ec2-user

これは、次のコマンドを発行することで修正されました。

$ chmod og-rwx/home/ec2-user

これが他の人の助けになることを願っています。

14
Bryan Rink

インスタンスを再起動した後、DNS名が変更されたことに注意してください。私はこれに何度か落ちました。キーファイルはまだ有効でしたが、「サーバー名」が変更されました。

12
Postal

ありがとうございました!

ここで@Trevorの回答に感謝します。この小さな問題を追加して、今後この問題を回避するために使用します。

便利さ

アベイラビリティーゾーンごとに異なるキーペアを作成する必要があるため、それらすべてとそれらを使用するコマンドを管理するのは非常に面倒になります。 ~/.ssh/configで適切にセットアップすると、sshコマンドは次のように簡単になります。

ssh ec2-52-10-20-30.us-west-2.compute.amazonaws.com

これは、米国西部2アベイラビリティゾーンにあるサーバーの完全なパブリックDNSです。このため、適切なユーザー名とキーが選択されます。

## ~/.ssh/config

Host *.us-west-2.compute.amazonaws.com
    User ec2-user
    IdentityFile ~/.ssh/bruno-bronosky-aws-us-west-2.pem
3
Bruno Bronosky

EC2インスタンスがUbuntu AMI 14.04を使用する場合。 EC2インスタンスのIPの前に「ubuntu @」を追加してみてください。

ssh -i [key name] ubuntu@[EC2 instance ip]
2
TYMG

秘密鍵へのパスが正しいことを確認してください。

Sshクライアントが、提供しようとしている秘密キーを見つけられない場合、奇妙なことに、エラーは発生しません!そのキーは使用されません。これは、.ssh/id_dsaおよび.ssh/id_ecdsaの下にあるキーを使用し、もちろん公開キー認証を失います。

1
Seeker

私も受け取りました:許可が拒否されました。

私は使用しました:

ssh -v -i ~/.ssh/pemfile [email protected]

応答は次のとおりです。

debug1: No more authentication methods to try.

次のコマンドを入力します。

ssh-add -l

しかし、応答は空でした

だから、私はペンファイルがフォーマットについて何か間違っていると思う。次に、ec2 webからダウンロードしたペンファイルを見つけて移動しました。この前に、新しいファイルを作成し、ダウンロードしたpemファイルからディレクトリ「.ssh」にテキストを解析してから、次の操作を行いました。

ssh-add filename

成功しました。

0
Alex Yao

〜/ .ssh/id_rsa.pubの内容をEC2インスタンスの〜/ .ssh/authorized_keysにコピーすることでこれを解決しました。

これはドキュメントで指定されています: http://docs.aws.Amazon.com/opsworks/latest/userguide/security-ssh-access.html

次に、このコマンドを使用してsshを実行できます。

ssh ec2-user@[ip.address]
0
ChrisJF

私は一日中答えをインターネットで探しました。私の問題はまったく同じです。許可の問題をいじり、前後に変更しましたが、誰も私の問題を解決しませんでした。新しいキーでテストし、いくつかのインスタンスを開始/終了した後、最終的に、異なる地域で同じキー名を使用する必要があることがわかりました。

これは、「許可が拒否されました(公開鍵)」が私に起こった方法です:
1。練習帳に従って、us-east-1をデフォルトゾーンとして選択します
2。キー名「mykey」を作成します
3。その本の例に従って、AWSの世界を探検してください。
4。ある日、シドニーゾーンの速度をテストして、デフォルトとしてシドニーゾーンに切り替えてみてください。
5。考えずに「mykey」という名前の別のキーを作成しますが、それを使用して数日間CLI経由で接続することはしません。
6。 cliを使用してAWSに接続してみてください。
7。 「許可が拒否されました(公開鍵)」。
8。キー/ゾーンの問題に気付くまで、sshの問題をデバッグするのに何時間も費やしました。

これが私のような初心者に役立つことを願っています。

この問題を回避するには、キーに名前を付けるためのベストプラクティスは、その中にリージョンをアタッチすることだと思います。

0
FrankCJ

少なくとも初めてCLIからEC2に接続するのは少し面倒です。 `に行くと

[サービス]-> [計算]-> [EC2]-> [実行中のインスタンス]> sshするインスタンスを選択->接続

`次に、接続方法を説明するダイアログボックスが表示されます。その一部を以下に示します。

enter image description here

ec2-user@を前に付けずに4番を使用すると、次のようになります

Permission denied (publickey).

下記の「例:」に記載されているものをコピーして貼り付けてください。

0
tadtab

許可を600に変更しましたが、pemファイルの許可はすでに644でした。そしてそれはうまくいきました:pそれが役立つことを願っています

0
gaurav arora

同じ問題があった場合、ここであなたがすべきことです。まず、Windowsを使用している場合は、LinuxのようなBabunコマンドラインを使用します。そのコマンドラインを取得したら、それを開いてssh-i [key pair path] [username]@[EC2 public IP].キーペアのパスを見つけるには、キーが保存されているファイルに移動し、Shiftキーを押しながら右クリックして[パスのコピー]をクリックし、上記のコマンドのパスのある場所に貼り付けます。おそらく、貼り付けたパスの外側に ""マークと\バックスラッシュが表示されます。 「」マークを削除し、\バックスラッシュを通常のスラッシュ/に置き換えます。これは私が持っていたこのような状況でうまくいきました。

0
user9357559

私の場合、この理由は、chmodを使用してルートディレクトリフォルダの権限を変更したためです。 AWSウェブサイトでは、別の一時インスタンスでアクセス許可を元に戻す長い方法について説明しています。ただし、古いインスタンスを終了して別のインスタンスを起動したところ、今回はルートディレクトリのアクセス許可を変更せず、すべて問題ありません。

0
entropy