私はAWSイメージとKubuntuイメージの両方をセットアップしました。どちらもCISベンチマーク原則に従っています。https://www.cisecurity.org/cis-benchmarks/適用されました。
この間、奇妙としか言いようのない認証の問題が散発的に発生しました。
パスワードはマシンによって受け入れられなくなり、パスワードが間違っていると報告されます。
私は次の方法で問題を解決しようとしました:
- ユーザー フォルダーのファイル権限を確認しています。 残念ながら、権限は問題なく、パスワードなしの認証は引き続き完全に機能します。
- マシンの2番目のユーザーを介してルートを使用して、（、、、、およびそれらの対応する）の8つのセキュリティファイルのファイル権限を確認します。
/etc/運passwdが悪く、権限は正常で、他のすべてのユーザーは動作しますgroups。shadowgshadow - 2番目のユーザーを介してルートを使用して、上記のファイル内の行の整合性を確認します。運が悪く、行は他の行と同様に集計されます。
- 2 番目のユーザー経由でルートを使用して、問題のあるユーザーのパスワードをリセットします。運が悪く、パスワードが空のユーザーに設定されている場合でも、ユーザーはログインできません。
- 2 番目のユーザー経由で root を使用して、古いユーザーを削除して新しいユーザーを作成します。問題が再発するまでは機能します。
Amazon 上のイメージは必要に応じて新しいボックスにスピンアップされ、Kubuntu マシンは頻繁には使用されませんが、これによりいくつかの興味深い点が明らかになりました。
- これは、認証が数回成功した後に発生するようです。Amazon イメージのスプールが数回の認証では問題なく、その後失敗すると、別の Amazon イメージのスプールも同じ時点で失敗します。
- ルートパーティションをフラッシュすると、この問題が解決するようです。Kubuntu ボックスでは /var と /home が別々のパーティションにあるため、問題の一部ではないことが分かります。
私が望んでいるのは、この問題の原因を正確に把握して解決し、新しいユーザーを作成して所有権を定期的に再割り当てする必要がないようにすることです。
答え1
PAM は成功したログインを失敗したログインとしてカウントし、失敗回数をリセットしていなかったことが判明しました。
PAMの標準設定には、この問題を防ぐための行が欠けているようです。具体的には、次の行が/sbin/pam.d/common_account標準として必要です。
account required pam_tally2.so
これを追加すると、成功したログインによって失敗したログインが正しく 0 にリセットされていることが確認できました。