発生した事象
CentOS 環境において、以下の問題が発生した。
- 正しいユーザー名・パスワードを入力している
- 認証エラーは表示されない
- にもかかわらず ログインできない（ログイン直後に弾かれる）
対象は主に コンソールログイン（TTYログイン）。
SSHログインも同様の影響を受ける可能性がある。
まず行った対処：シングルユーザーモードでの復旧
ログインできないため、通常の手段では調査ができない。
そのため、シングルユーザーモードで起動し、root権限で環境に入る。
手順
-
サーバー起動時、GRUB画面で
eキーを押す -
起動エントリの編集画面で 2番目の行を選択し、再度
e -
行末に以下を追加
1 -
Enterで保存し、
bキーで起動
これにより **シングルユーザーモード（rootログイン）**で起動できる。
原因調査：PAM設定ファイルの確認
シングルユーザーモードでログイン後、
PAM（Pluggable Authentication Modules）の設定を確認した。
対象ファイル
/etc/pam.d/login
問題のある設定
session required /lib/security/pam_limits.so
問題点の本質
この環境は 64bit Linux であるにもかかわらず、
- PAMが 32bit用ディレクトリ
/lib/securityを参照している - 実際のライブラリは
/lib64/security/pam_limits.soに存在する
その結果：
- 認証（auth）は通過
- session 初期化で失敗
- ログインが完了せず失敗する
という非常に分かりづらい挙動になる。
解決策：PAM設定の修正
修正内容
以下の行を修正する。
- session required /lib/security/pam_limits.so
+ session required /lib64/security/pam_limits.so
行が存在しない場合
最終行に以下を追加する。
session required /lib64/security/pam_limits.so
保存後、再起動する。
shutdown -r now
結果
- 正しいパスワードで正常にログイン可能
- コンソールログイン／SSHログインともに復旧
なぜ「CentOSの問題」として知られているのか
この問題はよく 「CentOSで発生するログイン不可トラブル」 として紹介されるが、
CentOS固有の不具合ではない。
背景
-
CentOS 6 / 7 世代では
-
/libと/lib64の使い分けが明確 - 古い設定ファイルが残りやすい
-
-
以下のようなケースで発生しやすい
- 32bit → 64bit 環境への移行
- 古い手順書の流用
- minimal install 後の手動設定
- 設定ファイルのコピー流用
本質的な原因：PAM + 64bit Linux + パス不整合
この事象は、以下3条件が揃ったときに発生する。
- PAMを利用している
- 64bit Linux環境
- PAM設定で誤ったライブラリパスを参照している
👉 つまり、
PAM + 64bit Linux + パス不整合による一般的な構成トラブル
である。
他ディストリビューションでも起こり得るか？
| OS | 発生可能性 |
|---|---|
| CentOS 6 / 7 | 高い |
| RHEL 6 / 7 | 高い |
| Amazon Linux 1 | あり |
| Rocky / AlmaLinux | 低い（初期状態ではほぼ起きない） |
| Ubuntu / Debian | 低い（構成が異なる） |
※ OSというより 世代・移行履歴・手動設定の有無 が重要。
参考：ログで確認できる兆候
以下のようなログが /var/log/secure に出力される場合がある。
PAM unable to dlopen(/lib/security/pam_limits.so)
ログインできないがパスワードは正しい、という場合は
PAMのsession設定を疑うのが有効。
まとめ
- 正しいパスワードでもログインできない原因は PAMのsession失敗
- 原因は 64bit環境でのライブラリパス不整合
- CentOS特有ではなく、RHEL系Linux全般で起こり得る
-
/etc/pam.d/login（およびsshd）の確認は必須
おわりに
ログイン不可系のトラブルは焦りやすいが、
「認証は通るが session で落ちる」ケースを知っていると切り分けが一気に楽になる。
同様の構成を扱う方の参考になれば幸いです。