ユーザ名*の認証失敗が多すぎる

これは通常、不注意で複数の ssh 鍵をサーバに提供した場合に発生します。あまりにも多くの鍵が提供されると、サーバはどの鍵も拒否します。

この現象は、-v コマンドに ssh フラグを追加して詳細な出力を得ることで、自分で確認することができます。サーバが接続を拒否するまで、多くの鍵が提供されていることがわかるでしょう。サーバが接続を拒否するまでは、"Too many authentication failures for [user]“と表示されます。verbose モードがない場合は、"Connection reset by peer”_ という曖昧なメッセージだけが表示されます。

無関係な鍵が提供されないようにするには、~/.ssh/config (クライアントマシン上の) ファイルの各ホストエントリに、以下のように IdentitiesOnly を追加して明示的に指定しなければなりません。

ssh ホストの設定を使用していない場合は、 ssh-add -D コマンドで以下のように正しい鍵を明示的に指定する必要があります:

Host www.somehost.com
  IdentityFile ~/.ssh/key_for_somehost_rsa
  IdentitiesOnly yes
  Port 22

_注意: ‘IdentitiesOnly yes’ パラメータは引用符で区切ってください。

もっと簡単な方法を見つけました（パスワード認証を使用している場合）:

ssh -o PubkeyAuthentication=no username@hostname.com

これは非キー認証を強制します。すぐにログオンできました。 参考

私もこのエラーが発生していたのですが、サーバが 6 回までの試行を受け入れるように設定されていたために発生していたことがわかりました:

/etc/ssh/sshd_config
...
...
#MaxAuthTries 6

IdentitiesOnly yes ファイルの ~/.ssh/config の設定に加えて、他にもいくつかのオプションがあります。2. MaxAuthTries ディレクトリに存在する鍵ペアのいくつかを削除して ~/.ssh/ を実行する 3. 明示的に鍵を ssh-add -D ファイル内の特定のホストにリンクする

このように:

host foo
hostname foo.example.com
IdentityFile /home/YOU/.ssh/foo

1. 与えられた接続の試みでより多くの鍵を受け入れるようになるので、それが ssh サーバを少し弱体化させることを考えると、それについて行くにはおそらく良い方法ではありません。ここでは、ブルートフォース攻撃のベクトルを考えてください。あなたが必要としない鍵を持っていて、永久に削除することができると仮定して、行くための良い方法です。IdentitiesOnlyを設定するアプローチは、おそらくこの問題に対処するための好ましい方法です!

これを ~/.ssh/config に追加しました。

Host *
IdentitiesOnly yes

デフォルトで IdentitiesOnly=yes オプションが有効になっています。秘密鍵で接続する必要がある場合は -i オプションで指定します。

以下のような SSH エラーが発生した場合:

$ Received disconnect from host: 2: Too many authentication failures for root

これは、(私のシステムのデフォルトでは) .ssh ディレクトリに 5 つ以上の DSA/RSA identity ファイルが保存されていて、コマンドラインで ‘-i’ オプションが指定されていない場合に発生する可能性があります。しかし、 sshd は 5 回の不正なログインを試みると接続を切断します (ここでもデフォルトは異なるかもしれません)。

もし .ssh ディレクトリにいくつかの秘密鍵がある場合は、’-o’ オプションの引数を使用してコマンドラインで「公開鍵認証」を無効にすることができます。

パスワードを持っていて、単にパスワードを使ってログインしたい場合は、以下のようにします。

パスワード認証のみを使用し、Public-key を使用せず、"keyboard-interactive" (パスワードを含むスーパーセット) というやや誤解されやすい言葉を使用しないようにするには、コマンドラインから以下のようにします:

ssh -o PreferredAuthentications=password user@example.com

Davidさんが言っていたのを思い出して、このIdentitiesOnly yesを.ssh/設定に追加すると、ssh -o PubkeyAuthentication=no.

と同じことをしてくれます。さて、ローカルマシンに戻って、次のように

.ssh/authorized_keys と入力してください。これで、公開鍵を使った ssh が再利用可能になるはずです。

これは古いスレッドであることは知っていますが、私は同じエラーメッセージに遭遇したことをここに追加したかったのですが、それは鍵を使用していたユーザではなく、.ssh フォルダの所有者が root であることが原因でした。私は次のコマンドを実行して問題を修正しました:

sudo chown -R user:user /home/user/.ssh

また、.ssh フォルダのパーミッションが正しいことを確認しました:

sudo chmod 700 /home/user/.ssh

.ssh ディレクトリ内のファイルは 600 のパーミッションを持っている必要があります:

sudo chmod 600 /home/user/.ssh/authorized_keys

私の場合、問題はディレクトリのパーミッションでした。これは私のためにそれを修正しました:

$ chmod 750 ~;chmod 700 ~/.ssh

これは私のための楽しいものでした。リモートログインに使用していたキーボードとは異なるローカライズモードで、ローカルでパスワードを変更していたことが判明した。これにより、私のパスワードは事実上、私が思っていたものとは違ったものになってしまいました。これは、私の特殊文字の一つがキーボードが言っていたものと違っていたからでしょう。

このメッセージは、リモートの SSH サーバで許可されている制限の中で、認証に失敗した回数が多すぎることが原因です。これは潜在的に SSH エージェントに追加された ID が多すぎることを意味しています。

いくつかの提案があります:

• -v を追加して、(使用している ID が多すぎるかどうか)確認してください。
• また、ssh-add -l ですべての ID を削除し、関連するものだけを追加することもできます。

• SSH サーバにアクセスしている場合は、ssh-add -d オプションをチェックしてください (参照: ssh-add -D )。

• このヘルプのどれもない場合は、正しい資格情報やファイルを使用しているかどうかを確認してください。

公開鍵を.ssh/authorized_keys2に入れていたのですが、サーバーが.ssh/authorized_keys:

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile .ssh/authorized_keys

しか読めないように設定されていたので、ファイルを.ssh/authorized_keysに移動したら、無事に自分の鍵でログインできるようになりました。

私の場合、ユーザー名「ubuntu」を使用していたので、それは起こっていましたが、このインスタンスのユーザー名は「ec2-user」でした

私は “John T "が提案したことを行った後、私はこのエラーを得ました：

Permission denied (publickey).

その後、私はこの回答で解決策（すなわち、ユーザー名を「ec2-user」に変更する）を見つけました。 https://stackoverflow.com/questions/1454629/aws-ssh-access-permission-denied-publickey-issue

このメッセージは、正しいユーザー名とパスワードが入力されていない場合に表示されます。