PuTTYターミナルを使用して、ユーザーroot @ HostのSSH接続を確立するいくつかの試みを行いました。その間、私は数回間違った資格情報を指定し、その後それらを正しく指定し、資格情報が受け入れられた後、sshセッションが
「サーバーが予期せずにネットワーク接続を閉じました」。
このエラーは、PuTTY端末によって報告されます。ローカルコンソールからroot @ localhostをsshしようとすると、正常に動作します。他のホストからotheruser @ Hostをsshしてもうまくいきます。したがって、ネットワーク接続の問題は有罪ではありません。 「ユーザーrootの認証失敗が多すぎます」ですが、PuTTYは別のエラーを報告しています。
問題はこのエラー状態から回復してPuTTYに再度ログインさせる方法 sshdの再起動は役に立たないようです
Sshへのrootログインが許可されていますか?
Sshd_configを確認し、rootログインが許可されていることを確認します。設定が変更された場合、sshdを再起動する必要があります。
「ユーザーrootの認証失敗が多すぎます」とは、SSHサーバーのMaxAuthTriesの制限を超えたを意味します。これは、クライアントが/home/USER/.ssh/に格納されているすべての可能なキーを使用して認証しようとしているためです。
この状況は、次の方法で解決できます。
Host host
IdentityFile /home/USER/.ssh/id_rsa
Host host2
IdentityFile /home/USER/.ssh/id_rsa2
次の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_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を試行する前に最大試行回数に達していた。
これは悪い習慣です。リモートボックスに通常のユーザーがいて、それを使用してssh経由で接続し、su/Sudoを使用してrootアクセスを取得するだけです。
私も同じ問題に直面しました。これは、Pageantを使用していて、多数のキーが読み込まれている場合に簡単に発生します、これらのサーバーは認証試行として公開鍵の各オファーをカウントするため。
(このアドバイスは here から引用されています。)
上記のAnonが投稿したように、別のユーザーを使用してsshアクセスを取得してから、su
コマンドを使用してroot
アクセスを取得することをお勧めします。
また、サーバーの/etc/ssh/sshd_config
ファイルでPermitRootLogin
を必ず有効にしてください。
次のコマンドを実行して、システムでこの問題を修正しました。
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でこの問題を修正しました。
他の回答は、ルートとして接続するための最良の方法、およびそのセキュリティへの影響を示していますが、明示的な質問は
このエラー状態から回復してPuTTYに再度ログインさせる方法
あなたが最後に接続したときにリモートサーバーが接続を落としたと述べました。
リモートサーバーでfail2ban(*)が実行されており、ログインに成功した後、IPが "jail"されたことがわかると思います。再度ログインを試行することでこれをテストでき、ログインプロンプトも表示されません。
2つの解決策があります。刑務所の時間を待つことができます。その時点で物事は通常に戻りますが、刑務所の時間は何でもかまいません。または、ログインする別のコンピュータを見つけて、それを実行し、IPを「jail解除」することができます。この場合、リモートサーバーの観点からは「異なる」ため、同じファイアウォールの背後にある別のコンピュータもおそらく機能しません。 。
(*)fail2banは、さまざまなログファイルを定期的にチェックし、ファイアウォールルールを調整して、クライアントから悪意のある可能性のある動作を検出したときにサーバーを「非表示」にすることができる非常に便利なデーモンです。 debianでは、特定のIPからの複数の失敗したsshログインを検出するように構成された箱から出して、3(おそらく)の後で、そのIPからのすべてのパケットをドロップします。スクリプト化されたブルートフォース攻撃を阻止するために素晴らしく機能します。
私のUbuntu 16.04サーバーで2つの簡単な手順を実行してこの問題を解決しました-
最初にvncサーバーを停止するか、プロセスを終了します-
vncserver -kill :1
そしてそれを再び開始します-
vncserver
その後、リモートデスクトップクライアントから接続します-
999.99.99.99:5901
できました!
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を取り除くことができました。
@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の回答に示されています)。