Amazon EC2インスタンスへのSSHアクセス時にアクセスが拒否されました（公開キー）[終了]

Amazon ec2インスタンスを使用したいのですが、次のエラーが発生しました。

Permission denied (publickey).

キーペアを作成し、.pemファイルをダウンロードしました。

与えられた：

chmod  600 pem file.

次に、このコマンド

ssh -i /home/kashif/serverkey.pem  ubuntu@ec2-54-227-242-179.compute-1.amazonaws.com

しかし、このエラーがあります：

Permission denied (publickey)

また、filezillaに接続してファイルをアップロード/ダウンロードするにはどうすればよいですか？

このエラーメッセージは、認証に失敗したことを意味します。

これらはそれを引き起こすことができる一般的な理由です：

1. 間違ったキーで接続しようとしています。このインスタンスがこのキーペアを使用していますか？
2. 間違ったユーザー名で接続しようとしています。ubuntuUbuntuのベースのAWSの配布のためのユーザ名があるが、いくつか他の人にそれのec2-user（またはadminいくつかのDebiansに、ボグダンKulbidaの答えによる）（もすることができroot、fedora下記参照します）
3. 間違ったホストに接続しようとしています。ログインしようとしているホストは正しいですか？

EC2インスタンスのファイル1.をめちゃくちゃにした場合にも発生することに注意し/home/<username>/.ssh/authorized_keysてください。

について2.、使用する必要があるユーザー名に関する情報がAMIイメージの説明に欠けていることがよくあります。しかし、いくつかはAWS EC2のドキュメントの箇条書きにあります4.：http : //docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html

sshコマンドを使用してインスタンスに接続します。秘密鍵（.pem）ファイルとuser_name @ public_dns_nameを指定します。Amazon Linuxの場合、ユーザー名はec2-userです。RHEL5の場合、ユーザー名はrootまたはec2-userのいずれかです。Ubuntuの場合、ユーザー名はubuntuです。Fedoraのために、ユーザー名のいずれかであるのFedoraやEC2ユーザー。SUSE Linuxの場合、ユーザー名はrootです。それ以外の場合、ec2-userおよびrootが機能しない場合は、AMIプロバイダーに確認してください。

最後に、認証が失敗する理由は他にもたくさんあることに注意してください。-vこの質問に対する他の多くの回答で説明されているように、SSHコマンドにオプションを追加して出力を読み取ろうとすると、SSHは通常、何が問題だったかについてかなり明確になります。

この場合、問題は鍵ペアの紛失から生じます。これについて：

• インスタンスのキーペアを変更する方法はありません。新しいキーペアを使用する新しいインスタンスを作成する必要があります。
• インスタンスがElastic Beanstalk上のアプリケーションで使用されている場合は、問題を回避できます。

次の手順に従ってください。

1. AWSマネジメントコンソールへのアクセス
2. Elastic Beanstalkタブを開く
3. [ すべてのアプリケーション]タブからアプリケーションを選択します
4. 左側の男性から設定を選択します
5. インスタンスギアをクリックします
6. ではサーバフォームチェックEC2キーペアの入力をして、新しい鍵ペアを選択します。作成したばかりの新しいキーペアを表示するには、リストを更新する必要がある場合があります。
7. セーブ
8. Elastic Beanstalkは、新しいキーペアに関連付けられた新しいインスタンスを作成します。

一般に、EC2インスタンスがインバウンドSSHトラフィックを受け入れることを許可する必要があることを覚えておいてください。

これを行うには、EC2インスタンスのセキュリティグループに特定のルールを作成する必要があります。次の手順に従ってください。

1. AWSマネジメントコンソールへのアクセス
2. EC2タブを開く
3. [ インスタンス]リストから、目的のインスタンスを選択します
4. [ 説明]タブで、インスタンスが使用しているセキュリティグループの名前をチェックします。
5. もう一度[ 説明 ] タブで [ ルールの表示 ]をクリックし、セキュリティグループにポート22のインバウンドSSHトラフィックのルールがあるかどうかを確認します
6. そうでない場合は、[ ネットワークとセキュリティ]メニューで[ セキュリティグループ ]を選択します
7. インスタンスで使用されているセキュリティグループを選択し、[ 受信 ] タブをクリックします。
8. [受信]タブの左側で、SSH受信トラフィックのルールを作成できます。
   • 新しいルールを作成する：SSH
   • ソース：インスタンスへのアクセス元となるIPアドレスまたはサブネットワーク
   • 注：インスタンスへの無制限のアクセスを許可する場合は、0.0.0.0 / 0を指定できますが、Amazonはこの方法を推奨していません
9. [ ルールの追加]をクリックして、変更を適用します
10. SSH経由でインスタンスに接続できるかどうかを確認します。

これが私を助けたように誰かを助けることができることを願っています。

これは私が問題を解決した方法です

ssh -i <key> ec2-user@<ec2 ip>

sudo前に置いた問題を解決しました

sudo ssh -i mykey.pem myec2.amazonaws.com

しかし、適切な解決策は、まず所有権を変更してから、Janus Troelsenが以下に述べるように、通常のユーザーとして接続することです。私の場合、それは：

chown wellington:wellington key.pem

使ってみてください

sudo ssh -i mykey.pem ubuntu@<ec2_ip_public_dns>

または

sudo ssh -i mykey.pem ec2-user@<ec2_ip_public_dns>

このエラーの別の考えられる原因：

ユーザーのホームディレクトリがグループ書き込み可能である場合、ユーザーはログインできません。

（Ubuntuインスタンスで再現。）

ubuntu 12.04 ltsマイクロインスタンスの場合、ユーザー名をオプションとして設定する必要がありました

ssh -i pemfile.pem -l ubuntu dns

次の手順を実行する必要があります。

1. Linuxを使用している場合は、sshクライアントまたはターミナルを開きます。
2. 秘密鍵ファイルを見つけて、ディレクトリを変更します。
   cd <path to your .pem file>
3. 以下のコマンドを実行します。
   chmod 400 <filename>.pem
ssh -i <filename>.pem ubuntu@<ipaddress.com>

ubuntuユーザーが作業していない場合は、で試してくださいec2-user。

同じ許可で苦労しましたが、明らかにエラーが拒否されました

key_parse_private2: missing begin marker 

私の状況では、原因は現在のユーザーのssh構成ファイル（〜/ .ssh / config）でした。

以下を使用します。

ssh -i ~/myKey.pem ec2-user@<IP address> -v 'exit'

最初の出力は次のとおりです。

debug1: Reading configuration data /home/ec2-user/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 56: Applying options for *
debug1: Hostname has changed; re-reading configuration
debug1: Reading configuration data /home/ec2-user/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config

...多くのデバッグ行がここでカットされます...

debug1: Next authentication method: publickey
debug1: Trying private key: /home/ec2-user/somekey.pem
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.

上記の3行目は、実際に問題が特定された場所です。しかし、私は下から4行（上）からデバッグメッセージを探し、誤解しました。キーに問題はありませんが、テストして他の構成と比較しました。

ユーザーのssh構成ファイルは、以下に示すように、意図しないグローバル設定を介してホストをリセットしました。最初のホスト行はコメントであってはなりません。

$ cat config
StrictHostKeyChecking=no
#Host myAlias
        user ec2-user
        Hostname bitbucket.org
#        IdentityFile ~/.ssh/somekey
#        IdentitiesOnly yes

Host my2ndAlias
        user myOtherUser
        Hostname bitbucket.org
        IdentityFile ~/.ssh/my2ndKey
        IdentitiesOnly yes

他の誰かがこれが役に立ったと思います。

Ubuntuインスタンスに接続するときに、ユーザー名（ubuntu）を追加するのを忘れました。だから私はこれを試しました：

ssh -i /path/my-key-pair.pem my-ec2-instance.amazonaws.com

そして正しい方法は

ssh -i /path/my-key-pair.pem ubuntu@my-ec2-instance.amazonaws.com

これは私に何度も起こりました。私はAmazon Linux AMI 2013.09.2とUbuntu Server 12.04.3 LTSを使用しましたが、どちらも無料枠です。

インスタンスを起動するたびに、表示を拒否する権限があります。私はこれを検証していませんが、私の理論では、サーバーにSSH接続しようとする前にサーバーが完全にセットアップされていません。許可なしで数回の試行が拒否された後、私は数分待ってから接続できます。この問題が発生している場合は、5分待ってから再試行することをお勧めします。

このエラーを引き起こす可能性のあるイライラするシナリオを次に示します。

別のインスタンス（インスタンスxyzなど）で作成したAMIから新しいインスタンスをランチする場合、新しいインスタンスは、インスタンスAが使用したのと同じキーのみを受け入れます。これは完全に理解できますが、新しいインスタンスを作成する段階的なプロセス中に、（最後のステップで）機能しないキーを選択または作成するように求められるため、混乱を招きます。

作成または選択したキーに関係なく、インスタンスXYZで使用していたキーのみが新しいインスタンスによって受け入れられます。

私も次のことがわかるまで、しばらくの間これに苦労しました：

eb ssh

あなたがプロジェクトディレクトリからそれを使用するとき、ビンゴバンゴは大騒ぎせず、あなたは

私自身の場合、私は次のことをしました：

chmod 400 <key.pem>

ssh -i <key.pem> ec2-user@ec2_public_dns (for debian)

私は最初にroot@部品を使用していて、このプロンプトが表示されました：

Please login as the user "ec2-user" rather than the user "root".

私はWindowsでWinSCPを使用しています。ファイルエクスプローラーとPuTTY SSHシェルの両方で動作し、Amazon EC2-VPC Linux にアクセスできます。pemファイルからPuTTYgenによって変換さchmod pem fileれて使用myfile.ppk されるため、何もする必要はありません。

私にも同じことが起こりましたが、起こっていたのは、ローカルマシンのキーチェーンから秘密鍵が失われたことです。

ssh-add -K

キーを再度追加すると、接続するsshコマンドが機能するように戻りました。

この問題は、以下のコマンドを使用してUbuntuボックスにログインすることで解決できます。

ssh -i ec2key.pem ubuntu@ec2-public-IP

キーとsshコマンドラインは2回は正しいものでしたが（稼働中のUbuntu 14.04インスタンスを複製しているのでわかっています）、上記のWade Andersonの提案に従って5分待っても、新しいインスタンスにSSHで接続できませんでした。

マシンを破壊して作り直さなければなりませんでした。これは2つの別々の状況で起こりました。最初は入らないので何が悪いのかわかりません。

したがって、この問題がある場合は、それを試してください。

次のことを確認する必要があります。

1. IPアドレスが正しいことを確認してください
2. 正しいキーを使用していることを確認してください
3. 正しいユーザー名を使用していることを確認してください。管理3.2。ec2-user 3.3。Ubuntu

同じ問題がありましたが、ユーザー名をubuntuに変更すると解決しました。AWSのドキュメントでは、ユーザーec2-userに言及しましたが、どういうわけか私にはうまくいきません。

私の秘密鍵は許可に設定されて400いたため、「許可が拒否されました」を「644」に設定すると役に立ちました。

key_load_private_type：拒否された権限は、私が取得していた特定のエラーです

解決： Sudo chmod 644 <key.pem>

注：644に設定する必要があります。400では機能しませんでした。

やってみると

ssh -i <.pem path> root@ec2-public-dns

を使用するようにアドバイスするメッセージが表示されますec2-user。

Please login as the user "ec2-user" rather than the user "root".

だから使う

ssh -i <.pem path> ec2-user@ec2-public-dns

私は同じ問題を抱えていましたが、それは非常に奇妙です。あなたがこれを実行するよりもすべて良いことをしていると確信している場合：EC2インスタンスのユーザーについて混乱があることがあります!! ec2-user、ubuntu、centosなどが表示される場合があります。そのため、ユーザー名でmachieを確認してください。

rootユーザーでログインすると、 ssh -i yourkey.pem (400 permission) root@<ip> エラーが発生し、使用可能なユーザー名が表示されます。次に、そのユーザーでログインします。

基本的なことですが、ログインしようとしているユーザーを必ず確認してください。私の場合、私は単なる気晴らしでした。rootユーザーを使用しようとしました：

ssh -i ~/keys/<key_name> root@111.111.111.111

しかし、別のユーザーでした：

ssh -i ~/keys/<key_name> dedeco@111.111.111.111

私は同じエラーがありましたが、異なる状況でした。私にとっては、多くの時間の後にリモートコンピュータに正常にsshで接続できた後、突然発生しました。私の問題の解決策をたくさん検索した後、ファイルのアクセス許可がありました。もちろん、私は自分のコンピューターまたはsshのファイル/ディレクトリに属する​​リモートのアクセス許可を変更しなかったので、奇妙です。だから良いarchlinux wikiからここにあります：

ローカルマシンの場合は、次のようにします。

$ chmod 700 ~/
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/id_ecdsa

リモートマシンの場合は、次のようにします。

$ chmod 700 ~/
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys

その後、私のsshは（公開鍵）の許可なしに再び動作し始めました。

別の考えられる問題：間違ったログインID

「使用方法」を確認してください

上記のすべての良い提案ですが、私が遭遇したのは、事前に作成されたインスタンスを選択したことです。インスタンスが起動したら、使用方法を確認します。手順で「bitnami」を使用することになっていたときに、秘密鍵のログインIDを誤って使用しました（例：bitnami @ domain -i key.pem）

私は同様のエラーがありました

debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: xxxx.pem
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

私の問題は、からのrun-on-start-upスクリプトのエラーが原因でインスタンスが適切に起動しなかったことでした Step 3: Configure instance detail下Advanced details:

私が入力したと思ったこと：

#include
 https://xxxx/bootstrap.sh


実際に入力されたものはインスタンスのセットアップを壊します

#include

https://xxxx/bootstrap.sh

したがって、インスタンス側の公開鍵は作成されませんでした

大文字と小文字が区別されます。

誤り：SSH EC2-user @ XXX.XX.XX.XX -i MyEC2KeyPair.pem

正しい例：SSH ec2-user @ XXX.XX.XX.XX -i MyEC2KeyPair.pem

あるマシンからはSSHを実行できましたが、別のマシンからはできませんでした。間違った秘密鍵を使用していたことがわかりました。

これを理解する方法は、次のように秘密鍵から公開鍵を取得することでした。

ssh-keygen -y -f ./myprivatekey.pem

出てきたものが~/.ssh/authorized_keysEC2インスタンスの内容と一致しませんでした。

上記のトップランクの回答はすべて正確であり、ほとんどの場合に機能するはずです。私の場合とは異なる場合は、~/.ssh/known_hostssshを実行しようとしたマシン上のファイルを単に削除しただけで、問題は解決しました。その後接続できました。