ユーザーに次回ログイン時のパスワード変更を強制する方法｜複数対応まで

新規アカウントを発行したとき、または仮パスワードをユーザーへ伝えたとき、「自分で変更してもらわないと困る」という運用要件は頻繁に発生します。口頭でお願いするだけでは変更されないまま放置されるリスクがあります。ここでは chage コマンドを使い、次回ログイン時にパスワード変更を必須とさせる手順を解説します。

まず結論：1コマンドで強制変更フラグを立てる

パスワードの有効期限を「0日目（過去扱い）」にリセットすることで、次回ログイン時にパスワード変更が強制されます。

# 対象ユーザーのパスワードを即時失効させる
chage -d 0 alice

このコマンドを実行すると、対象ユーザーは次回ログイン時に現在のパスワードを入力したあと、新しいパスワードの設定を求められます。変更を完了させるまでシェルには入れません。

同じ効果を持つ別の書き方として passwd --expire も利用できます。

passwd --expire alice

どちらを使っても結果は同じです。スクリプトや引き継ぎを意識するなら chage -d 0 の方がオプションの意味が読み取りやすく、後から見たときに意図が明確です。

設定が入ったかどうかを必ず確認する

設定後は chage -l で状態を確認してください。思い込みによる取りこぼしを防げます。

chage -l alice

正しく設定されていれば、出力は以下のようになります。

Last password change                              : password must be changed
Password expires                                  : password must be changed
Password inactive                                 : password must be changed
Account expires                                   : never
Minimum number of days between password change    : 0
Maximum number of days between password change    : 99999
Number of days of warning before password expires : 7

Last password change 欄が password must be changed になっていれば設定は正常です。具体的な日付が表示されている場合は設定が反映されていません。コマンドを再実行するか、実行時のユーザー権限（root または sudo）を確認してください。

複数ユーザーへの一括適用

組織異動や一斉パスワードリセットの際、複数アカウントをまとめて処理したい場合はループで回します。

# 対象ユーザーをスペース区切りで列挙する
for user in alice bob carol; do
  chage -d 0 "$user"
  echo "$user: 強制変更フラグ設定済み"
done

対象が多い場合はファイルで管理する方が安全です。

# users.txt に1行1ユーザー名で記載しておく
while IFS= read -r user; do
  chage -d 0 "$user" && echo "$user: OK" || echo "$user: FAILED"
done < users.txt

実行後にサンプル数件を chage -l で目視確認するひと手間を加えると、処理の取りこぼしやスペルミスを確実に拾えます。

SSH鍵認証ユーザーには別の対処が必要

ここは見落としやすい落とし穴です。 SSH公開鍵認証のみで接続しているユーザーは、PAMのパスワード変更プロンプトをスキップしてシェルに入れてしまう場合があります。chage -d 0 はパスワード認証フローの中で動作するため、鍵認証ユーザーへの強制変更としては機能しないことがあります。

ある運用現場では、この点を考慮して初回だけパスワード認証でログインさせ、変更完了後に鍵認証へ切り替えるフローを採用しています。セキュリティポリシーによっては /etc/ssh/sshd_config の ForceCommand でパスワード変更スクリプトを強制する方法も有効です。

いずれの方法を選ぶにしても、root アカウントや管理用サービスアカウントには誤って設定しないよう注意してください。ログインできなくなるリスクがあります。

パスワードポリシーと組み合わせた実務設定

「変更は強制できたが、すぐに元のパスワードへ戻された」という問題を防ぐには、PAMのパスワード履歴管理と組み合わせるのが定石です。

RHEL系（AlmaLinux・Rocky Linux）では pam_pwhistory.so を使います。

# /etc/pam.d/system-auth（RHEL系）に以下が含まれているか確認する
grep pwhistory /etc/pam.d/system-auth

# 含まれていなければ password セクションへ追記
# password    required    pam_pwhistory.so  remember=5 use_authtok

Ubuntu/Debian系では libpam-pwquality パッケージと pam_pwhistory を組み合わせます。

# インストール確認
dpkg -l libpam-pwquality

# /etc/pam.d/common-password に履歴管理が入っているか確認
grep -i history /etc/pam.d/common-password

変更後のパスワード有効期限を組織ポリシーに合わせて設定しておくと、次回以降も定期変更が継続されます。

# 最大90日でパスワードを期限切れにし、7日前から警告を表示する
chage -M 90 -W 7 alice

# 設定を確認
chage -l alice

設定変更後のディスク書き込みを確定させる

chage や passwd の変更は /etc/shadow ファイルへの書き込みを伴います。現代の Linux では systemd がシャットダウン時にバッファのフラッシュを自動処理するため、通常は追加の操作は不要です。

ただし仮想マシンの強制停止やストレージ障害が想定されるシビアな環境では、手動で sync を実行してディスクへの書き込みを即時確定させる運用もあります。

# バッファをディスクに書き出す
sync

コマンドは何も表示せずにプロンプトへ戻りますが、これは正常な動作です。sync は書き込み完了後に終了するコマンドのため、プロンプトが返ってきた時点でディスクへの書き込みは完了しています。

systemctl poweroff や shutdown -h now など正規の手順でシステムを停止する限り、sync を手動実行しなくてもデータが失われることはありません。強制電源断のリスクがある環境や、重要な一括処理の直後に念のため実行する、という使い方が現実的です。