2010-09-12 17:14:13 +0000 2010-09-12 17:14:13 +0000
264
264

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

私は ssh アクセスを有効にした hostgator アカウントを持っています。このコマンドで生成された .pub 鍵ファイルをアップロードしようとすると:

rsync -av -e "ssh -p2222" /home/user/.ssh/key.pub username@111.222.33.44:.ssh/authorized_keys

と表示され続けます:

Received disconnect from 111.222.33.44: 2: Too many authentication failures for username rsync: connection unexpectedly closed (0 bytes received so far) [sender] rsync error: unexplained error (code 255) at io.c(601) [sender=3.0.7]

認証に失敗するまでは、以前は ssh を使っていじっていました。しかし、今では認証失敗カウンタがリセットされないようです(今では12時間以上待っている、技術サポートは、それが30分から1時間後にリセットされた “と仮定 "し、別の男は私に言った "それはあなたがユーザー名でログインしようとするたびにリセットされます "と、jeesh)。私もSlicehostのカスタムサーバーで設定していたのですが、これらの人たちよりも問題が少なかったです。おそらくそれはサーバー側ではなく、クライアント側の何かです。

回答 (14)

423
423
423
2010-09-12 17:53:29 +0000

これは通常、不注意で複数の 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’ パラメータは引用符で区切ってください。

195
195
195
2012-03-25 00:14:49 +0000

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

ssh -o PubkeyAuthentication=no username@hostname.com

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

27
27
27
2011-06-09 04:56:25 +0000

私もこのエラーが発生していたのですが、サーバが 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を設定するアプローチは、おそらくこの問題に対処するための好ましい方法です!
7
7
7
2014-07-23 17:29:54 +0000

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

Host *
IdentitiesOnly yes

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

6
6
6
2013-09-20 21:44:02 +0000

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

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

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

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

6
6
6
2015-06-19 14:22:41 +0000

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

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

ssh -o PreferredAuthentications=password user@example.com
3
3
3
2014-01-25 05:48:51 +0000

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

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

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

2
2
2
2014-06-13 17:37:06 +0000

これは古いスレッドであることは知っていますが、私は同じエラーメッセージに遭遇したことをここに追加したかったのですが、それは鍵を使用していたユーザではなく、.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
1
1
1
2016-02-20 22:57:15 +0000

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

$ chmod 750 ~;chmod 700 ~/.ssh
0
0
0
2019-11-24 01:41:40 +0000

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

0
0
0
2018-04-12 13:28:15 +0000

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

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

  • -v を追加して、(使用している ID が多すぎるかどうか)確認してください。
  • また、ssh-add -l ですべての ID を削除し、関連するものだけを追加することもできます。
  • SSH サーバにアクセスしている場合は、ssh-add -d オプションをチェックしてください (参照: ssh-add -D )。

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

0
0
0
2017-05-05 07:57:18 +0000

公開鍵を.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に移動したら、無事に自分の鍵でログインできるようになりました。

0
0
0
2014-11-19 08:10:08 +0000

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

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

Permission denied (publickey).

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

-1
-1
-1
2016-09-26 15:23:15 +0000

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