su試行のパスワードの前にpam_tally2incrememts
ここでも同様の動作 がありますが、これは別の根本的な原因であるか、この失敗はSSHキーが原因ではないため、少なくとも別の解決策が必要であると思います。
当社はLinux監査を受けており、3回の不正なパスワードの試行に対してPAMアカウントのロックを有効にする必要があります。私は以前にPAMの経験がありません。
pam_tally2 -u testuserを実行した直後でパスワードを入力する前にsu testuserを実行すると、パスワードをまだ入力していなくても、失敗のpam_tallyはすでに1になっています。
上記にリンクした場合、パスワードの事前インクリメントはSSHキー交換の失敗が原因であると理解していますが、man suを読んだ後、キー交換が含まれているようには見えません。だから私の質問は「なぜsuはパスワードを入力する前にpam_tallyをインクリメントさせるのですか？」です。
ログイン試行/ブロックがすべてsshd_config、PAM、fail2ban、および/etc/login.defの間で一致するように最善を尽くしていますが、pam_tallyが予期しないイベントをカウントする場合は注意が必要です。
OSはUbuntuサーバー14.04です
サーバーに対して行われたPAM構成の変更のみが/etc/pam.d/common-authにあり、この行を先頭に追加します。
auth required pam_tally2.so deny=3 unlock_time=900
ありがとう！
pam_tally2の機能を注意深く読むと、表示されている動作が完全に説明されます。ログイン時に失敗した試行回数がいくつ発生したかを確認する必要があります。ただし、 man ページで説明されています（私の強調）：
このモジュールは、試行されたアクセスの数を維持します
したがって、意図したとおりに動作しています。 su userを実行すると、パスワードをまだ入力しているかどうか（正しいか間違っているか）に関係なく、すぐにアクセスを試みました。その後、正しいパスワードを入力すると、集計は0にリセットされます。最大試行回数を3に設定したので、を超えるとすぐにエラーが発生します—エラーを生成するのは4回目の試行です。
動作は正しく、pam_tally2が実際に何をするかを理解したので、それは合理的です。