OpenSSH 6.7の `preauth`エラーログエントリは、特定の人間の注意を必要としますか？
インターネットに公開する必要のあるLinux（特にDebian Jessie）サーバーは、ログにさまざまなOpenSSH 6.7 preauthエラーを吐き出します。たとえば、次のようになります（明確にするためにタイムスタンプは省略されています）。
- エラー：A.B.C.Dからの切断を受信しました：3：com.jcraft.jsch.JSchException：認証に失敗しました[preauth]
- 致命的：鍵交換方式をネゴシエートできません[事前認証]
- 致命的：一致する暗号が見つかりません：クライアント...サーバー... [事前認証]
- A.B.C.Dからの切断を受信しました：11：通常のシャットダウン、[preauth]を再生していただきありがとうございます
- A.B.C.Dからの切断を受信しました：11：ok [preauth]
等々。
プローブ自体についてはそれほど心配していません。システムは最新の状態に保たれ、OpenSSH構成は現在のベストプラクティスに従ってかなり強化されており、追加の保護（fail2banなど）が実施されています。
preauth OpenSSHログエントリが特定の人間の注意を必要とする理由はありますか？
質問への回答 SSHログの「通常のシャットダウン、[preauth]を再生していただきありがとうございます」とはどういう意味ですか？ は、その場合の特定のケースを示します質問は無視しても安全です。私の質問はもっと一般的です。
いくつかの OpenSSHを強化するための特定の手順 を実行したようです。
これらの変更の副作用として、比較的新しいOpenSSHバージョンの実行と組み合わせると、接続障害に関するより詳細なログエントリが多数表示されます。
表示されているすべての事前認証メッセージはこのカテゴリに分類され、何らかの理由で接続に失敗したクライアントを表しています。ほとんどの場合、これらの接続は、クライアントがユーザー名とパスワードを試行できるようになる前に失敗します。
これらのログエントリを処理する最善の方法は、ログエントリをログアグリゲーターにフィードし、セキュリティ研究者が確認できるようにニースグラフを作成することです。彼らは個々の人間の介入を必要としません。
もちろん、パスワードが試行され失敗したことを示すメッセージには引き続き介入する必要があります。ここでは、fail2banなどの既存のツールが役立ちますが、ほとんどのsshブルートフォースボットはまだ最新の暗号を使用していないため、禁止リストは以前よりもはるかに小さくなっています（これらのメッセージのほとんどの根本原因です）。
介入が必要になる可能性のあるもう1つの場所は、古いバージョンのsshクライアントを使用しているために接続できなくなったauthorizedユーザーです（例： PuTTYまたはFileZillaの古いバージョン）。クライアントを最新バージョンに更新すると、これらの問題が修正されます。