回答:
私はDenyHostsを使用しているので、少なくともそのために答えることができます：
正しく使用する限り、取り返しのつかない短所はありません。
/etc/hosts.allowます。パスワードの入力に失敗しただけでロックアウトし、職場の誰かがジョークとしてルートアカウントにログインして、職場のIPをブラックリストに登録しようとしたところ、突然接続できなかった理由を見つけるのに数日かかりました仕事から私のネットワークへもう1つは、iptablesに依存するfail2banです（したがって、sshだけでなく、あらゆるサービスで動作します）。fail2banでは、次のことができます。
DenyHostsの「デメリット」の1つは、tcpラッパーが必要なため、/ etc / hosts.denyファイルを参照するサービスでのみ機能することです。しかし、DenyHostsとの公平を期すために、sshdはほとんどのLinuxディストリビューションでTCPラッパーを使用するようにコンパイルされています。また、DenyHostsはfail2banよりも簡単に設定できます（ただし、強力ではありません）。
スキャンベースの攻撃に対する単純で実際的な効果的な保護は、標準ポートを使用しないことです。443（httpsポート）は、弱いパスワードを解読することのないさまざまなブルートフォース攻撃にさらされ、デフォルトのポート（22）よりも多くのファイアウォールを介して機能する可能性があります。
SSHのブルートフォース攻撃を防ぐためのほとんどの方法は、自己DoSに最適な方法です（おっと、構成を台無しにしました！ 、攻撃者は私と同じサブネット（動的IP範囲、大学のネットワークなど）のマシンから来た/破壊されており、私も禁止されています！）。
数か所からしかログインしない場合は、送信元IPアドレスをホワイトリストに登録できます。外出先でラップトップや携帯電話からsshを実行したい場合、これは明らかに良くありません。
IPv6接続のみをリッスンするsshデーモンを使用すると、数年前からスキャンから保護されます。ただし、多くのファイアウォールでは、IPv6を合理的な方法で転送できません。
言及していないもう1つの方法は、ポートノッキングです。自己DoSの問題（設定ミス以外）の影響は受けませんが、ファイアウォールをうまく通過せず、接続の確立に数秒の遅延を追加する可能性があります。
適切なパスワードを持っている場合、またはパスワード認証なしで生活できる場合は、パスワード認証を無効にします。（キーとワンタイムパスワードは、ほとんどのユースケースで十分です。sshキーを格納するのに十分なクライアントマシンを信頼していない場合、キーロガーがないことも信頼しません）。その後、ブルートフォース攻撃はCPUと帯域幅を少し犠牲にしますが、侵入にさらされないでください（キーがどれもDebianの低エントロピーOpenSSLからのものでないことを確認した限り））。
全体として、ポートを変更しても露出が大幅に減少するわけではないことに注意してください。スキャンの回数は減りますが、カットできるのは、古い脆弱性と脆弱なパスワードを悪用しようとする手間のかからないことだけです。デーモンを最新の状態に保ち、妥当なパスワードまたは妥当な試行レート制限を強制する限り、ポートを切り替えることはセキュリティ対策よりも不利です。
.ssh/configです。ファイアウォールが通過できない場合、ロックアウトは問題です。最も簡単な解決策は、ポート22に固執し、443でリッスンすることです。ポートを切り替えてもセキュリティが向上しないことに同意します。 。SSHデーモンがパスワード認証をサポートできないと考える理由がわかりませんsshd_config。最も一般的な実装であるOpenSSHに行を追加するだけです。