「ユーザーrootの認証エラーが多すぎます」から回復する方法

puttyターミナルを使用して、ユーザーroot @ hostのSSH接続を確立しようといくつか試みました。その間、間違った資格情報を数回指定し、その後、それらを正しく指定し、資格情報が受け入れられた後、sshセッションが

「サーバーがネットワーク接続を予期せず閉じました」。

このエラーは、putty端末によって報告されます。ローカルコンソールからroot @ localhostをsshしようとすると、正常に動作します。他のホストからotheruser @ hostをsshするときにも正常に動作します。したがって、ネットワーク接続の問題は無罪です。私が考えている唯一のエラーは、「ユーザーrootに対する認証の失敗が多すぎます」ですが、puttyは別のエラーを報告しました。

問題は、このエラー状態から回復して、パテに再度ログインさせる方法です。sshdの再起動は役に立たないようです

sshへのrootログインが許可されていますか？

sshd_configを確認し、ルートログインが許可されていることを確認します。設定を変更した場合、sshdを再起動する必要があります。

「ユーザーrootの認証エラーが多すぎる」とは、SSHサーバーのMaxAuthTriesの制限を超えたことを意味します。これは、クライアントが/home/USER/.ssh/に保存されているすべての可能なキーで認証しようとしているために起こります。

この状況は、次の方法で解決できます。

1. ssh -i / path / to / id_rsa root @ host
2. /home/USER/.ssh/configでHost / IdentityFileのペアを指定します。
   • Host host
   • IdentityFile /home/USER/.ssh/id_rsa
   • Host host2
   • IdentityFile /home/USER/.ssh/id_rsa2
3. / etc / ssh / sshd_configのSSHサーバーのMaxAuthTries値を増やします（推奨されません）。

次のSSHエラーが表示された場合：

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

これは、.sshディレクトリに5つ以上のDSA / RSA IDファイルが格納されている場合（私のシステムのデフォルト）に発生する可能性があります。この場合-i、コマンドラインでオプションが指定されていない場合、sshクライアントは最初に各ID（秘密鍵）を使用してログインを試行し、次にパスワード認証のプロンプトを表示します。ただし、sshdは、5回の不正なログイン試行後に接続をドロップします（再びデフォルトが異なる場合があります）。

したがって、.sshディレクトリに多数の秘密キーがPublic Key Authenticationある-o場合は、オプションの引数を使用してコマンドラインで無効にすることができます。

例えば：

$ ssh -o PubkeyAuthentication=no root@host

リモートマシンで/ etc / sshd_configを開き、値を変更します

MaxAuthTries 30

これは、複数のキーをインストールした場合、または複数の接続を開いた場合の典型的な問題です。サーバーが各キーを段階的にチェックし、MaxAuthTriesが3に設定されている場合、最初の3回目の試行後に切断されます。典型的なsshセキュリティ。

問題を分析するには、リモートマシンへの接続中に冗長モードを使用することをお勧めします。

ssh -v -p port_number user @ servername

このフォーラムのほとんどの人々のように推測するのは間違っており、時間の無駄です。最初に問題を分析し、情報を収集してから質問してください。

楽しんで。

これは悪い習慣です。リモートボックスに通常のユーザーを置き、それを使用してsshで接続し、su / sudoを使用してルートアクセスを取得するだけです。

私にとって、この問題は、接続先のホスト用に以下のssh_configを作成することで解決しました。

（〜/ .ssh / config）

Host example
HostName example.com
User admin
IdentityFile ~/path/to/ssh_key_rsa
IdentitiesOnly=yes

この問題は、~/.sshフォルダー内に16個程度のsshキーが多すぎるために発生しました。そして、構成にこれらのIdentityFileAND IdentitiesOnlyディレクティブの両方がなければ、私のマシンは明らかにすべてのキーを~/.ssh試し、正しいIdentityFileを試みる前に最大試行回数に達しました。

上記のAnonが投稿したように、別のユーザーを使用してsshアクセスsuを取得し、コマンドを使用してアクセスすることをお勧めしますroot。

また、サーバー上のファイルで必ず有効にPermitRootLoginしてください/etc/ssh/sshd_config。

私も同じ問題に直面しました。これは、Pageantを使用しており、多数のキーがロードされている場合、これらのサーバーは公開キーの各オファーを認証試行としてカウントするため、簡単に発生します。

（このアドバイスはここから取られています。）

次のコマンドを実行して、システムのこの問題を修正しました。

eval $(ssh-agent)
ssh-add  ~/.ssh/keyname

次に、リモートマシンでsshを試します

他の箇所で指摘されているように問題が完全に解決されるまでこの問題に一時的に対処するには、ユーザーのPAM集計をリセットして、再試行できるようにします。

pam_tally --reset --user <USERNAME>
pam_tally2 --reset --user <USERNAME>

私は同様の問題に噛まれました。しかし、本当の原因はForwardAgent yes、パイプに沿ったマシンの設定ファイルにあったことです。マシンAからマシンB、マシンCに接続していました。

エラーメッセージは、B-> Cからのssh試行で表示されましたが、Aが転送をアクティブにしていることが原因でした。したがって、Cは最初にAからすべてのキーを提供され、その後Bからのみ提供されました。

Aにもう1つキーを追加すると、突然表示されました。

Macでこの問題を修正しました：

1. 「sudo passwd root」でルートパスワードを設定してから
2. 「nano / etc / ssh_config」を使用してssh構成ファイルを編集および保存し、
3. RSAAuthenticationをyesではなく「no」に変更します。

OK、だから私の場合、これはかなり奇妙だった、ここに行く...

SSHキーを持つ標準のVagrant VMがあり、Puttyを使用してSSHで接続できます。PHPStormでの展開中に取得しようとすると、too many authentication failuresエラーが発生します。それで私はを増やしMaxAuthTriesてsshd_config、それから私はAuth failedエラーで打たれたAuth cancel。

今、私はなぜこれを試みたのかはっきりとは知りませんが、PHPStormの展開ウィンドウのSSHキーパスの最後にドットを追加しました。こんな感じでした：

C:\Users\Deadpool\\.ssh\chimichanga

そして今ではこのようになっています：

C:\Users\Deadpool\\.ssh\chimichanga.

そしてそれは動作します...私の「.ssh」フォルダには、さらにファイルがあります：

chimichanga - copy of "id_rsa" from vagrant machine
chimichanga.ppk
chimichanga.pub

私はそのfcukingドットが何をするのかわかり.ppkませんが、ファイルの使用は機能しないので、魔法のようなものだと思います;）ああ、その「ドットトリック」の後にMaxAuthTriesを取り除くことができました。

他の回答は、ルートとして接続するための最良の方法とそのセキュリティへの影響を示していますが、明示的な質問は

このエラー状態から回復し、パテに再度ログインさせる方法は？

あなたが最後に接続したときに言及すると、リモートサーバーは接続を切断しました。

リモートサーバーでfail2ban（*）が実行されており、ログインに成功した後にIPが「投獄された」ことがわかると思います。これをテストするには、もう一度ログインしてみてください。ログインプロンプトも表示されません。

2つの解決策があります。刑務所時間を待つことができます。その時点で物事は単純に通常に戻りますが、刑務所時間は何でもかまいません。または、ログインする別のコンピューターを見つけて実行し、IPを「脱獄」できます。この場合、「異なる」はリモートサーバーの観点からであるため、同じファイアウォールの背後にある別のコンピューターもおそらく動作しません。

（*）fail2banは、定期的にさまざまなログファイルをチェックし、ファイアウォールルールを調整して、クライアントから潜在的に悪意のある動作を検出したときにサーバーを「消失」させることができる非常に便利なデーモンです。debianでは、特定のIPからの複数の失敗したsshログインを検出するように構成されており、3（私が思うに）後、そのIPからすべてのパケットをドロップします。これらのスクリプト化されたブルートフォース攻撃を阻止するために見事に機能します。

別の答えで述べた@suffererのように、いくつかのLinuxディストリビューションは、たとえば、SSHなどの外部の目に見えるサービスのブルートフォース攻撃から保護するためのモニターを含めますDenyHostsかfail2ban。これらのモニターは、ログファイルをチェックして失敗した試行を探し、失敗が多すぎるIPアドレスをブロックするフィルターを追加します（数はsshd構成から独立して設定可能です）。

ディストリビューションにが含まれfail2banており、iptablesファイアウォールにルールを追加するサービスを保護している場合、次のコマンドを使用して、監視されているサービスまたは「jail」を確認できます。

sudo fail2ban-client status

SSHサービスの刑務所はsshdであるため、使用できるIPが禁止されているかどうかを確認するには、次のようにします。

sudo fail2ban-client status sshd

いくつかのIP abcdの禁止を解除するには：

sudo fail2ban-client set sshd unbanip a.b.c.d

がある場合DenyHosts、禁止リストは/etc/hosts.denyファイルにあります。このファイルをルートとして直接編集できます。一部のIP abcdに永続的なアクセスを許可sshd:a.b.c.dするには、/ etc / hosts.allowファイルに行を追加します。

いつものように、manコマンドはあなたの友人です：

man fail2ban
man hosts.deny

他の同様のユーティリティが存在するはずですが、私はこれらを使用しただけです。

sshd構成で許可される再試行回数を増やしても、禁止されたIPは解放されず、同じ接続でより多くの失敗が許可されることに注意してください。許可されている数を超えた場合、ユーザー/攻撃者は単純に再接続して、さらにn回試行します。

他のサービスには禁止リストが統合されていました（VNCサーバーの再起動に関するRajnesh Thakurの回答に示されているように）。

Ubuntu 16.04サーバーで2つの簡単な手順でこの問題を解決しました-

最初にvncサーバーを停止するか、プロセスを強制終了します-

vncserver -kill :1

その後、もう一度起動します-

vncserver

その後、リモートデスクトップクライアントから接続します-

192.0.2.99:5901

完了!!

以下の解決手順に従ってください

1. / etc / ssh / sshd_configをバックアップします
2. sshd_configのMaxAuthTriesの値を増やす
3. stopsrc -s sshd; startsrc -s sshd

上記の変更後に再度確認してください

「SServerは切断されたメッセージタイプ2（プロトコルエラー）を送信しました：ユーザーの認証エラーが多すぎます」というメッセージが表示されるという同じ問題がありました

すべてのssh（.ppkキー）を削除し、AD統合サーバーにログインすることでこの問題を解決しました。