ローカルUbuntuからAmazon EC2サーバーにSSHでアクセスしようとすると「Permission denied（publickey）」が表示されるのはなぜですか？

Amazon EC2インスタンスのクラウドで実行されているアプリケーションのインスタンスがあり、ローカルUbuntuから接続する必要があります。それは、ローカルのubuntuとラップトップの1つでうまく働きます。別のローカルUbuntuでSSHからEC2にアクセスしようとすると、「Permission denied（publickey）」というメッセージが表示されました。私にはとても奇妙です。

1つのインスタンスまたは証明書へのIPアクセスが制限されているAmazon EC2のセキュリティ設定に関する何らかの問題を、再生成する必要があると考えています。

誰もが解決策を知っていますか？

この状況で最初に行うことは、の-vオプションを使用してssh、どのタイプの認証が試行され、どのような結果になるかを確認することです。それは状況を啓発するのに役立ちますか？

質問の更新では、「別のローカルUbuntuについて」と述べています。ssh秘密鍵を他のマシンにコピーしましたか？

明示的に言及されていないため、sshdはデフォルトでauthorized_keysファイルのアクセス許可に対して非常に厳しいです。したがって、ユーザー以外のユーザーauthorized_keysが書き込み可能であるか、ユーザー以外のユーザーが書き込み可能にできる場合、認証は拒否されます（sshdがで構成されている場合を除くStrictModes no）

「書き込み可能」とは、親ディレクトリのいずれかがユーザー以外のユーザーに書き込み可能な場合、それらのディレクトリの変更を許可されたユーザーは、authorized_keysを変更/置換できるように権限の変更を開始できることを意味します。

さらに、/home/username/.sshディレクトリがユーザーによって所有されていないため、ユーザーにキーを読み取る権限がない場合、問題が発生する可能性があります。

drwxr-xr-x 7 jane jane 4096 Jan 22 02:10 /home/jane
drwx------ 2 root root 4096 Jan 22 03:28 /home/jane/.ssh

janeは.sshファイルを所有していないことに注意してください。これを修正する

chown -R jane:jane /home/jane/.ssh

これらの種類のファイルシステムのアクセス許可の問題はには表示されssh -vず、ログレベルをDEBUGに設定するまで、sshdログ（！）にも表示されません。

• 編集/etc/ssh/sshd_config。LogLevel DEBUGどこかで読み込む行が必要です。ディストリビューションが提供するメカニズムを使用してSSHサーバーをリロードします。（service sshd reloadRHEL / CentOS / Scientificで。）グレースフルリロードは、既存のセッションをドロップしません。
• もう一度認証してみてください。
• 認証機能のログがどこにあるかを調べて、それらを読み取ります。（IIRC、/var/log/auth.logDebianベースのディストリビューション、/var/log/secureRHEL / CentOS / Scientificで。）

ファイルシステムのアクセス許可エラーを含むデバッグ出力で何が問題なのかを簡単に解決できます。変更を元に戻すことを忘れないでください/etc/ssh/sshd_config！

-lオプションを追加するのを忘れたため、このエラーを受け取りました。私のローカルユーザー名はリモートシステムのものとは異なりました。

これはあなたの質問には答えませんが、私の問題に対する答えを探してここに来ました。

Ubuntu AMIをベースにした新しいインスタンスでこのメッセージを受け取りました。-iオプションを使用してPEMを提供していましたが、「Permission denied（publickey）」が表示されたままでした。

私の問題は、正しいユーザーを使用していなかったことです。sshをubuntu @ ec2で実行することにより、正常に機能しました。

ssh -v（もちろん私の意見では）より読みやすいものはtail -f /var/log/auth.logです。接続しようとしているときに、接続しようとしているサーバーで実行する必要があります。エラーはプレーンテキストで表示されます。

これは私の問題を解決するのに役立ちました：

ユーザーのグループがAllowGroupsにリストされていないため、xx.yy.comのユーザー[username]は許可されません

/ etc / ssh / sshd_configファイルを確認してください。そこで、言う行を見つけます

PasswordAuthentication no

その行は、noではなくyesと言うように修正する必要があります。また、後でsshdサーバーを再起動します。

sudo /etc/init.d/ssh restart

おそらく現在のポスターには関係ありませんが、同様の状況への回答を検索するときにこれを見つける他の人を助けるかもしれません。Amazonにsshキーペアを生成させる代わりに、独自の標準のデフォルトssh公開キーをAmazonにアップロードし、EC2インスタンスの実行時に指定することをお勧めします。

これにより、sshで「-i」タイプの構文を削除し、標準オプションでrsyncを使用できます。また、すべてのEC2リージョンで同じsshキーを使用できます。

このプロセスに関する記事をここに書きました：

Amazon EC2への個人用sshキーのアップロード
http://alestic.com/2010/10/ec2-ssh-keys

奇妙なことに、私の問題は、サーバーが再起動され、新しいDNS名が発行されたことでした。古いDNS名を使用していました。これは馬鹿げているように聞こえますが、これを理解するにはしばらく時間がかかりました。

Dropbearを実行しているCyanogenMod電話に接続しようとしている場合は、次の行を実行して、すべてがすべて許可されていることを確認する必要があります。

chmod 600 /data/dropbear/.ssh/authorized_keys

または

chmod 700 /data/dropbear/.ssh/authorized_keys # In case of MacOS X 10.6-10.8

そして

chmod 755 /data/dropbear/ /data/dropbear/.ssh

これは私のためにそれを修正しました、さもなければ何も接続できません。

あなたはCentOSの5を使用している場合は、設定することもできますStrictModes noの中で/etc/ssh/sshd_config。NIS / NFSを使用して/ homeディレクトリを共有しており、すべてのアクセス許可を正しく設定していますが、常にパスワードの入力を求められました。設定したらStrictModes no、問題はなくなりました！

グレッグの答えは、それをよりうまく撃つ方法を説明していますが、実際の問題は、トランザクションの片側（クライアント）にsshキーを設定し、パスワードベースの認証ではなく公開キー認証を試みていることです。EC2インスタンスに対応する公開キーがないため、これは機能しません。

私は同じ問題を抱えていましたが、機能しなかったたくさんの解決策を試した後、ルーターのファイアウォールのSSHポートを開きました（私のルーターのファイアウォールのコントロールパネルは混乱しているので、何が起こっているのかわかりません）。とにかく、それはそれを修正しました:)

スーパーあなたが得るエラーがGRR、作成された接続のいくつかの種類があったことを意味し、パーミッション拒否されたことを血まみれに迷惑。

私はおそらく次のすべての手順に従っていましたが、同じ問題を抱えていました

$ ec2-authorize default -p 22

しかし、私はus-west-1リージョンでインスタンスを開始しました。したがって、上記のコマンドでもそれを指定する必要があります。

$ ec2-authorize default -p 22 --region us-west-1

このコマンドの後、インスタンスにsshすることができました。この問題に気付く前に少し時間を費やし、この投稿が他の人に役立つことを願っています。

これはまれなケースですが、selinuxを有効にして、authorized_keysを含むディレクトリ（共有ホームディレクトリなど）にnfsを使用している場合は、selinuxを無効にする必要があります（セキュリティ上の理由でお勧めしませんが、一時的に無効にすることができます）これが問題の原因であるかどうかを確認します）またはselinuxがnfsホームディレクトリを使用できるようにします。詳細は明確ではありませんが、これはうまくいきました setsebool -P use_nfs_home_dirs 1

誤ってユーザーのホームディレクトリにグループ書き込み権限を追加した後、同じ問題が発生しました。

tail -f /var/log/secureマシンで実行してエラーを確認することで、これが原因であることを発見しましたAuthentication refused: bad ownership or modes for directory /home/<username>。