とにかくRSAキーログインのみが許可されているときにSSHにDenyhostsを使用するポイントはありますか？
そうです、適切なRSAキーを構成することによってのみボックスにSSHで接続できる場合、SSHにもDenyhostsを使用する意味はありますか？または、DenyhostsはSSHのキーボードインタラクティブ/パスワードログインのみを調べていますか？
誤解しないでください。Denyhostsは絶対的なマックパパですが、最近、キーボードインタラクティブログインを完全にオフにして、Denyhostsを実行し続ける価値があるかどうか疑問に思いました。
（Denyhostsがわからない場合は、基本的に、SSHにアクセスするために試行を保持しているが、ユーザー名/パスワードが間違っているなどのIPブラックリストを維持および使用します。）
私が読んだところ、DenyHostsを使い続ける理由は2つあります。
- ログイン失敗処理は依然としてリソースを消費するため、それを使用するとリソースが少なくなります。
- DenyHostsを使用したログファイルは、DenyHostsを使用しないログファイルよりもはるかに小さくなります。
それらのいずれかがあなたにとって本当に重要でない場合、DenyHostsはあなたのために何もしていません。
それは、「悪いアクター/人」が追加のリソースを非難することを最小限に抑えます。
そのボックスで実行されている他のサービスによって異なります。オンラインストアを備えたウェブサーバーの場合、ホストが誤って拒否されたためにビジネスを失う可能性があります。ただし、特に独自の拒否ホストデータのみを使用している場合は、そうなる可能性は低いと思われます。
一方、ロックダウンされたsshサーバーよりも安全性が低い可能性のある他のサービスを実行している場合、攻撃者がsshにうんざりしている場合、または実際に使用している場合は、他のサービスを保護することを拒否し続ける価値があります。共有データ。
長くも短くも、誤検知の心配がない場合（たとえば、サーバーへのアクセスに失敗する可能性のある人が別の方法で連絡を取り、関係を損なうことはありません！）、そうしない理由はありません。ホストを拒否し続けます。また、その楽しみ;）
他の回答に追加するために、denyhosts（例： Fail2ban ）のようなツールについて読んだときに私が遭遇した注意の言葉が1つあります（ArchWikiの通知の形で）：
警告：IPブラックリストを使用すると、些細な攻撃を阻止できますが、追加のデーモンと正常なロギングに依存します（特に攻撃者がサーバーを攻撃している場合、/ varを含むパーティションがいっぱいになる可能性があります）。さらに、攻撃者があなたのIPアドレスを知っている場合、攻撃者はなりすましの送信元ヘッダーを含むパケットを送信し、サーバーからロックアウトされる可能性があります。 .。
したがって、特に公開鍵認証のみを許可する場合は、非標準のポートを使用すること（ポート22でのブラインド攻撃を回避するため）を検討し、意図的に拒否ホストを使用しないことを検討する価値があります。