web-dev-qa-db-ja.com

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

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

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

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

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

sshputty
70
user11722

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

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

8
damorg

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

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

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

次の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
98
Will Verna

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

MaxAuthTries 30

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

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

ssh -v -p port_number user @ servername

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

楽しんで。

17
user59664

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

（〜/ .ssh/config）

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

この問題が発生したのは、~/.sshフォルダーに16個ほどのsshキーが多すぎるためです。そして、これらのIdentityFileおよびIdentitiesOnlyディレクティブの両方が設定に含まれていないと、私のマシンは明らかに~/.sshのすべてのキーを試行し、正しいIdentityFileを試行する前に最大試行回数に達していた。

15
Ninjaxor

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

12
Anonymous

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

（このアドバイスは here から引用されています。）

6
Prabath Dolawatta

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

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

6
Rodent43

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

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

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

5
Sunil shakya

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

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

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

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

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

2
Igor Stoppa

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

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

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

このエラー状態から回復してPuTTYに再度ログインさせる方法

あなたが最後に接続したときにリモートサーバーが接続を落としたと述べました。

リモートサーバーでfail2ban（*）が実行されており、ログインに成功した後、IPが "jail"されたことがわかると思います。再度ログインを試行することでこれをテストでき、ログインプロンプトも表示されません。

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

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

0
Sufferer

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

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

vncserver -kill :1

そしてそれを再び開始します-

vncserver

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

999.99.99.99:5901

できました！

0
Rajnesh Thakur

OK、それで私の場合これはかなり奇妙でした、ここにそれは行きます...

標準の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を取り除くことができました。

0
Adam Witorean

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

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

Sudo fail2ban-client status

SSHサービスのjailはsshdなので、使用できる禁止IPがあるかどうかを確認するには、次のようにします。

Sudo fail2ban-client status sshd

一部のIP a.b.c.dの禁止を解除するには：

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

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

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

man fail2ban
man hosts.deny

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

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

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

0
Fjor