本記事には広告(アフィリエイトリンク)が含まれます。

AlmaLinux 9 ユーザー・グループ管理

AlmaLinux 9 のサーバーを運用するうえで、ユーザーとグループの管理は避けて通れない基本操作です。本記事では、ユーザーの追加・変更・削除、グループ管理、パスワードポリシー、sudo による特権管理、UID/GID の採番ルール、アカウントのロック・無効化、umask の設定まで、企業のサーバー運用チームが日常的に扱う作業を実行例つきでまとめています。入社1〜3年目のインフラエンジニアが、現場でそのまま使えるリファレンスとして活用できる構成です。

コマンド早見表

やりたいことコマンド
ユーザー追加useradd -m -c ‘GECOS’ -s /bin/bash -G wheel ユーザー名
ユーザー情報変更usermod -aG グループ ユーザー名
ユーザー削除userdel -r ユーザー名
グループ追加groupadd -g GID グループ名
グループ名変更groupmod -n 新名 旧名
グループ削除groupdel グループ名
パスワード設定passwd ユーザー名
パスワード有効期限設定chage -M 90 -W 14 -I 30 ユーザー名
パスワード有効期限確認chage -l ユーザー名
sudo 権限編集visudo
自分の sudo 権限確認sudo -l
ユーザー情報確認id ユーザー名
ログイン履歴last / lastlog
アカウントロックpasswd -l ユーザー名
アカウントアンロックpasswd -u ユーザー名
ロック状態確認passwd -S ユーザー名
umask 確認umask / umask -S
孤立ファイル捜索find / -nouser -o -nogroup

前提条件

項目
OSAlmaLinux 9.6(Sage Margay)
カーネル5.14.0-570.12.1.el9_6.x86_64
インストールタイプ最小限のインストール(Minimal Install)
実行ユーザーdeveloper(UID 1000、wheel グループ所属、sudo 権限あり)
プロンプト記号# は root 権限での実行、$ は一般ユーザーでの実行

1. ユーザー管理の仕組み

Linux のユーザー管理は、4 つの設定ファイルで構成されています。コマンドを実行する前に、これらのファイルの構造を理解しておくと、トラブル発生時に原因を特定しやすくなります。

/etc/passwd

すべてのユーザーアカウント情報を保持するファイルです。各行が 1 ユーザーに対応し、コロン区切りで 7 つのフィールドがあります。

実行コマンド:

$ getent passwd developer

実行結果:

developer:x:1000:1000:developer:/home/developer:/bin/bash
フィールド値の例意味
ユーザー名developerログイン名
パスワードxx は /etc/shadow にハッシュが格納されていることを示す
UID1000ユーザー ID(数値)
GID1000プライマリグループ ID
GECOSdeveloperコメント欄(氏名や連絡先を記載する。GECOS はかつての汎用電子計算機互換オペレーティングシステムの略称に由来する)
ホームディレクトリ/home/developerログイン時のカレントディレクトリ
ログインシェル/bin/bashログイン時に起動されるシェル

/etc/passwd の先頭には、OS インストール時に作成されるシステムアカウントが並んでいます。

実行コマンド:

$ head -5 /etc/passwd

実行結果:

root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin

root の UID は 0 で、すべてのシステム操作が可能な特権アカウントです。bin、daemon、adm などのシステムアカウントは、ログインシェルが /sbin/nologin に設定されており、対話的なログインはできません。

/etc/shadow

パスワードのハッシュ値と有効期限情報を保持するファイルです。root のみ読み取り可能で、一般ユーザーからは閲覧できません。

developer ユーザーの shadow エントリ例を示します。

developer:$6$edCdSYECF2n2dE7e$k3mQF0GrSiOPHuc.i4HwI22q4KK29UUBklcQYgtn2ff7i7O3sYSn7p9QpnvjqN3aFP5T6wZHLSzk9sBW1Ca6o.::0:99999:7:::
フィールド意味
$6$…SHA-512($6$)でハッシュ化されたパスワード
!!(2つの感嘆符)パスワード未設定(ログイン不可)
*(アスタリスク)アカウントが無効化されている
空欄パスワードなしでログイン可能(セキュリティ上危険)

コロンで区切られた残りのフィールドは、最終パスワード変更日(エポックからの日数)、最短変更間隔、最長有効日数、警告日数、無効化猶予日数、アカウント有効期限、予約フィールドです。

/etc/group

グループ情報を保持するファイルです。各行が 1 グループに対応し、コロン区切りで 4 つのフィールドがあります。

実行コマンド:

$ getent group wheel

実行結果:

wheel:x:10:developer
フィールド値の例意味
グループ名wheelグループの名前
パスワードx通常は使用しない(x で固定)
GID10グループ ID(数値)
メンバーリストdeveloperこのグループに所属するユーザー(カンマ区切り)

メンバーリストに表示されるのは補助グループとして所属しているユーザーです。プライマリグループとしてのみ所属しているユーザーはここには表示されません。

/etc/login.defs

ユーザー作成時のデフォルト値やパスワードポリシーの初期値を定義するファイルです。useradd コマンドや passwd コマンドがこの設定を参照します。

AlmaLinux 9 のデフォルト設定値は以下の通りです。

UMASK		022
PASS_MAX_DAYS	99999
PASS_MIN_DAYS	0
PASS_WARN_AGE	7
UID_MIN                  1000
UID_MAX                 60000
GID_MIN                  1000
GID_MAX                 60000
CREATE_HOME	yes
設定項目デフォルト値意味
UID_MIN1000一般ユーザーに割り当てる UID の最小値
UID_MAX60000一般ユーザーに割り当てる UID の最大値
PASS_MAX_DAYS99999パスワードの最長有効日数(99999 は実質無期限)
PASS_MIN_DAYS0パスワード変更後、次に変更できるまでの最短日数
PASS_WARN_AGE7パスワード期限切れの何日前から警告するか
CREATE_HOMEyesuseradd 時にホームディレクトリを自動作成するか
UMASK022ユーザー作成時のホームディレクトリに適用される umask 値

PASS_MAX_DAYS のデフォルトは実質無期限

AlmaLinux 9 のデフォルトでは PASS_MAX_DAYS が 99999(約273年)に設定されています。企業の運用では、セキュリティポリシーに従い 90 日程度に変更するのが一般的です。変更方法は第 4 章で解説します。

2. ユーザーの追加・変更・削除

useradd でユーザーを追加する

新しいユーザーを作成する基本コマンドです。企業の運用では、GECOS フィールドに氏名を記載し、必要なグループへの所属も同時に指定します。

実行コマンド:

# useradd -m -c 'Test User 01' -s /bin/bash -G wheel testuser01
オプション意味
-mホームディレクトリを作成する(/etc/login.defs の CREATE_HOME=yes なら省略可だが、明示推奨)
-c ‘Test User 01’GECOS フィールドに氏名やコメントを設定する
-s /bin/bashログインシェルを指定する
-G wheel補助グループに wheel を追加する(sudo 権限が必要な場合)

作成結果を確認します。

実行コマンド:

$ id testuser01

実行結果:

uid=1001(testuser01) gid=1001(testuser01) groups=1001(testuser01),10(wheel)

UID 1001 が自動採番され、プライマリグループとして testuser01(GID 1001)が作成され、補助グループとして wheel(GID 10)に追加されています。

useradd のデフォルト値と /etc/skel

useradd コマンドのデフォルト設定は useradd -D で確認できます。この設定は /etc/default/useradd に保存されています。

実行コマンド:

# useradd -D

実行結果:

GROUP=100
HOME=/home
INACTIVE=-1
EXPIRE=
SHELL=/bin/bash
SKEL=/etc/skel
CREATE_MAIL_SPOOL=yes

/etc/skel は、新規ユーザーのホームディレクトリにコピーされるテンプレートディレクトリです。企業で統一した .bashrc や .vimrc を配布したい場合は、/etc/skel にファイルを配置しておきます。

usermod でユーザー情報を変更する

既存ユーザーの属性を変更するコマンドです。最も多い操作は、補助グループの追加です。

実行コマンド:

# usermod -aG wheel testuser01

-a を付け忘れると既存の補助グループがすべて削除される

usermod -G wheel testuser01 のように -a(append)を付けずに実行すると、testuser01 の補助グループが wheel のみに上書きされます。それまで所属していた他の補助グループはすべて外れます。グループ追加時は必ず -aG をセットで使用してください。誤って実行した場合は、usermod -aG グループ1,グループ2 ユーザー名 で再設定します。

ログインシェルの変更は -s オプションで行います。サービスアカウントなど対話的なログインが不要なユーザーには /sbin/nologin を設定します。

実行コマンド:

# usermod -s /sbin/nologin testuser01

切り戻し方法:

# usermod -s /bin/bash testuser01

ホームディレクトリの変更は -d オプションと -m オプションを組み合わせます。-m を付けると、旧ディレクトリの内容が新ディレクトリに移動されます。

実行コマンド:

# usermod -d /home/testuser01_new -m testuser01

切り戻し方法:

# usermod -d /home/testuser01 -m testuser01

userdel でユーザーを削除する

ユーザーを削除する前に、必ずホームディレクトリのバックアップを取得してください。削除後はデータを復元できません。

バックアップの実行コマンド:

# tar czf /backup/testuser01_home_$(date +%Y%m%d).tar.gz /home/testuser01

ユーザー削除の実行コマンド:

# userdel -r testuser01

-r オプションを付けると、ホームディレクトリとメールスプールも同時に削除されます。-r を付けずに削除すると、ホームディレクトリが残り、所有者のいないファイル(孤立ファイル)になります。

孤立ファイルの捜索

ユーザー削除後に、ファイルシステム上に所有者のいないファイルが残っていないか確認します。NFS 共有領域やアプリケーションのデータディレクトリに残存していることがあります。

実行コマンド:

# find / -nouser -o -nogroup 2>/dev/null

出力があった場合は、ファイルの内容を確認したうえで、必要に応じて所有者を変更するか削除してください。

3. グループの追加・変更・削除

Linux では、ファイルやディレクトリのアクセス権をグループ単位で制御します。プロジェクトチームやアプリケーション単位でグループを作成し、所属メンバーを管理するのが一般的な運用です。

プライマリグループと補助グループの違い

Linux のユーザーには必ず 1 つのプライマリグループと、0 個以上の補助グループが割り当てられます。

  • プライマリグループ:ユーザーがファイルを作成したとき、そのファイルのグループ所有者になるグループ。/etc/passwd の GID フィールドで指定される
  • 補助グループ:追加のアクセス権を得るために所属するグループ。/etc/group のメンバーリストに記載される

groupadd でグループを追加する

実行コマンド:

# groupadd -g 1001 appteam

-g オプションで GID を明示的に指定しています。複数サーバーで GID を統一する場合は、必ず GID を指定して作成します。GID を省略すると、システムが自動的に次の空き番号を割り当てます。

作成結果を確認します。

実行コマンド:

$ getent group appteam

実行結果:

appteam:x:1001:

groupmod でグループ名を変更する

実行コマンド:

# groupmod -n devteam appteam

実行結果:

$ getent group devteam

実行結果:

devteam:x:1001:

GID は変わらずグループ名のみが変更されます。ファイルのアクセス権は GID で管理されているため、グループ名の変更によるアクセス権への影響はありません。

切り戻し方法:

# groupmod -n appteam devteam

groupdel でグループを削除する

実行コマンド:

# groupdel devteam

プライマリグループに設定されているユーザーがいると削除できない

あるグループがいずれかのユーザーのプライマリグループに設定されている場合、groupdel は「cannot remove the primary group of user」エラーで失敗します。先にそのユーザーのプライマリグループを別のグループに変更(usermod -g 新グループ ユーザー名)するか、ユーザー自体を削除してから実行してください。

4. パスワード管理とポリシー設定

passwd でパスワードを設定する

ユーザー作成直後はパスワードが設定されていないため、ログインできません。passwd コマンドでパスワードを設定します。

実行コマンド:

# passwd testuser01

対話形式で新しいパスワードの入力を 2 回求められます。

chage でパスワード有効期限を設定する

企業のセキュリティポリシーでは、パスワードの定期変更を求められるのが一般的です。chage コマンドで個別ユーザーの有効期限を設定します。

実行コマンド:

# chage -M 90 -W 14 -I 30 testuser01
オプション意味
-M 90パスワードの最長有効日数を 90 日に設定する
-W 14期限切れの 14 日前から警告メッセージを表示する
-I 30期限切れ後 30 日間はログイン時にパスワード変更を強制し、30 日を過ぎるとアカウントが無効化される

設定内容を確認します。

実行コマンド:

$ chage -l developer

実行結果:

最終パスワード変更日				:なし
パスワード期限:					: なし
パスワード無効化中					: なし
アカウント期限切れ						: なし
パスワードが変更できるまでの最短日数		: 0
パスワードを変更しなくてよい最長日数		: 99999
パスワード期限が切れる前に警告される日数		: 7

上記は変更前の developer ユーザーの例です。PASS_MAX_DAYS が 99999 のため「パスワード期限: なし」と表示されています。

初回ログイン時にパスワード変更を強制する

新規ユーザーに初期パスワードを設定した後、初回ログイン時にパスワードの変更を強制する運用が一般的です。

実行コマンド:

# chage -d 0 testuser01

-d 0 は「最終パスワード変更日を 1970年1月1日(エポック)に設定する」という意味です。これにより、次回ログイン時にパスワードの有効期限切れと判定され、変更を求められます。

/etc/security/pwquality.conf でパスワードの複雑性を設定する

pwquality.conf は、PAM(Pluggable Authentication Modules:認証処理をモジュール化する仕組み)の pam_pwquality モジュールが参照する設定ファイルです。パスワードの最小文字数や、含めるべき文字種を制御します。

AlmaLinux 9 のデフォルトでは、すべての設定がコメントアウトされています。企業のセキュリティ要件に合わせて以下のように設定します。

実行コマンド:

# vi /etc/security/pwquality.conf

設定内容:

minlen = 12
dcredit = -1
ucredit = -1
lcredit = -1
ocredit = -1
設定項目意味
minlen12パスワードの最小文字数を 12 文字にする
dcredit-1数字を最低 1 文字含むことを必須にする(負の値は必須文字数)
ucredit-1大文字を最低 1 文字含むことを必須にする
lcredit-1小文字を最低 1 文字含むことを必須にする
ocredit-1記号を最低 1 文字含むことを必須にする

切り戻し方法:各行をコメントアウト(行頭に # を追加)すると、デフォルト設定に戻ります。

/etc/login.defs でパスワードポリシーの初期値を変更する

/etc/login.defs の設定は、新規ユーザー作成時の初期値として適用されます。既存ユーザーには影響しません。既存ユーザーの設定を変更するには chage コマンドを使用してください。

企業での一般的な設定例を示します。

PASS_MAX_DAYS   90
PASS_MIN_DAYS   1
PASS_WARN_AGE   14
設定項目推奨値理由
PASS_MAX_DAYS9090 日ごとのパスワード変更を強制する
PASS_MIN_DAYS1パスワード変更直後に再変更して元に戻す行為を防止する
PASS_WARN_AGE14期限切れの 14 日前から警告を表示し、変更忘れを防ぐ

5. sudo による特権管理

sudo は、一般ユーザーが root 権限でコマンドを実行するための仕組みです。初期設定編では「wheel グループに追加して sudo を有効化する」基本操作を扱いましたが、本章では「最小権限の原則に基づいた sudo 設計」を解説します。

visudo で sudoers を編集する

sudoers ファイルの編集には必ず visudo コマンドを使用します。visudo は保存時に構文チェックを行い、文法エラーがあると警告を表示して保存をキャンセルします。vi で直接 /etc/sudoers を編集すると、構文エラーがあってもそのまま保存され、sudo が使用不能になるリスクがあります。

実行コマンド:

# visudo

AlmaLinux 9 のデフォルトの sudoers 設定(有効行の抜粋)は以下の通りです。

Defaults   !visiblepw
Defaults    always_set_home
Defaults    match_group_by_gid
Defaults    always_query_group_plugin
Defaults    env_reset
Defaults    env_keep =  "COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS"
Defaults    env_keep += "MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE"
Defaults    env_keep += "LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES"
Defaults    env_keep += "LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE"
Defaults    env_keep += "LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY"
Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin
root	ALL=(ALL) 	ALL
%wheel	ALL=(ALL)	ALL

%wheel ALL=(ALL) ALL は「wheel グループのメンバーは、すべてのホストで、すべてのユーザーとして、すべてのコマンドを実行できる」という意味です。

sudoers の構文エラーは sudo 不能を引き起こす

visudo を使わずに /etc/sudoers を直接編集して構文エラーを書き込むと、すべてのユーザーが sudo を実行できなくなります。SSH 経由のリモート接続で作業中にこの状態になると、root 権限を取得する手段がなくなる可能性があります。回復手順は第 13 章「トラブルシューティング」で解説します。

/etc/sudoers.d/ で個別設定を管理する

/etc/sudoers を直接変更する代わりに、/etc/sudoers.d/ ディレクトリに個別のファイルを配置する方法が推奨されます。OS アップデート時に /etc/sudoers が上書きされても、/etc/sudoers.d/ 内のファイルは保持されるためです。

実行コマンド:

# visudo -f /etc/sudoers.d/appteam

設定内容の例:

%appteam ALL=(ALL) /usr/bin/systemctl restart httpd, /usr/bin/systemctl restart nginx

上記の設定では、appteam グループのメンバーに httpd と nginx の再起動のみを許可しています。この設定により、アプリケーションチームが Web サーバーのデプロイ後に自分たちで再起動できるようになりますが、それ以外の root 操作は許可されません。

NOPASSWD の限定使用

NOPASSWD を設定すると、sudo 実行時にパスワード入力を求められなくなります。監視ツール(Zabbix Agent や Nagios NRPE)がシステム情報を取得する際に使用する場面がありますが、一般ユーザーへの安易な適用はセキュリティリスクになります。

監視ツール用の設定例:

zabbix ALL=(ALL) NOPASSWD: /usr/sbin/dmidecode, /usr/bin/systemctl status *

NOPASSWD を ALL に設定してはいけない

NOPASSWD: ALL を設定すると、そのユーザーのアカウントが侵害された場合に攻撃者がパスワードなしで root 権限を取得できます。NOPASSWD は必要最小限のコマンドに限定し、設定した理由をコメントで残してください。

sudo -l で権限を確認する

自分に付与されている sudo 権限を確認するコマンドです。

実行コマンド:

$ sudo -l

実行結果(wheel グループ所属の場合):

ユーザー developer は alma-main 上で コマンドを実行できます:
    (ALL) ALL

sudo のログを確認する

sudo の実行ログは、誰がいつどのコマンドを root 権限で実行したかを追跡するために重要です。監査対応やインシデント調査で必要になります。

実行コマンド:

# journalctl _COMM=sudo --no-pager -n 20

/var/log/secure にも sudo の実行ログが記録されます。

実行コマンド:

# grep sudo /var/log/secure

6. UID/GID の統一管理

複数のサーバーを運用する環境では、UID と GID を全サーバーで統一しておくことが重要です。特に NFS(Network File System)で共有ディレクトリを使用する場合、UID/GID が不一致だと、別のユーザーのファイルにアクセスできてしまう、あるいはアクセスが拒否されるといった問題が発生します。

UID の採番ルール(企業での管理例)

/etc/login.defs で UID_MIN=1000、UID_MAX=60000 が設定されています。この範囲内で、組織の運用ルールに基づいた採番体系を設計します。

UID 範囲用途
0root
1〜999システムアカウント(useradd -r で作成)
1000〜1999正社員
2000〜2999協力会社・外部パートナー
3000〜3999サービスアカウント(アプリケーション用)
60001〜65534予約(使用しない)

この採番ルールを UID 台帳(スプレッドシートやCMDB)で管理し、新規ユーザー作成時に台帳から次の番号を払い出します。

UID の棚卸し

定期的に全ユーザーの UID を確認し、台帳との整合性を検証します。

実行コマンド:

$ getent passwd | awk -F: '{print $3,$1}' | sort -n

実行結果(抜粋):

0 root
1 bin
2 daemon
3 adm
4 lp
74 sshd
996 chrony
997 polkitd
998 sssd
999 systemd-coredump
1000 developer
1001 testuser01

UID 順にソートされた一覧が表示されます。台帳と突き合わせて、不明なアカウントが存在しないか確認してください。

7. ユーザー情報の確認コマンド

id(UID・GID・所属グループの確認)

実行コマンド:

$ id developer

実行結果:

uid=1000(developer) gid=1000(developer) groups=1000(developer),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

UID、プライマリ GID、所属する全グループ、SELinux コンテキストが 1 行で確認できます。

whoami / groups

実行コマンド:

$ whoami

実行結果:

developer

実行コマンド:

$ groups developer

実行結果:

developer : developer wheel

whoami は現在の実行ユーザー名を表示します。susudo で別のユーザーに切り替えた際に、今どのユーザーとして操作しているかを確認するのに使います。groups は指定ユーザーの所属グループを表示します。

getent(LDAP 環境でも使える統合検索)

getent は、/etc/passwd や /etc/group だけでなく、LDAP(Lightweight Directory Access Protocol:ディレクトリサービスにアクセスするためのプロトコル)や SSSD 経由のユーザー情報も統合的に検索できます。企業では Active Directory 連携で LDAP 認証を導入しているケースがあり、その場合は cat /etc/passwd では LDAP ユーザーが表示されません。getent を使えば、ローカルアカウントと LDAP アカウントの両方を取得できます。

実行コマンド:

$ getent passwd developer

実行結果:

developer:x:1000:1000:developer:/home/developer:/bin/bash

実行コマンド:

$ getent group wheel

実行結果:

wheel:x:10:developer

last / lastlog(ログイン履歴)

last はログイン・ログアウトの履歴を新しい順に表示します。lastlog はユーザーごとの最終ログイン日時を表示します。

実行コマンド:

$ last -n 10

実行コマンド:

$ lastlog

長期間ログインがないアカウントは、退職や異動で不要になったアカウントの可能性があります。定期的な棚卸し(第 12 章で解説)の際に確認してください。

w(現在ログイン中のユーザー)

実行コマンド:

$ w

現在ログイン中のユーザー、ログイン元、実行中のコマンドが表示されます。メンテナンス作業前に、他のユーザーがログインしていないか確認する際に使用します。

8. su と sudo の使い分け

su と su – の違い

susu -(ハイフン付き)は動作が異なります。ハイフンを付けると、対象ユーザーのログインシェルとして起動し、環境変数や PATH が正しく設定されます。

コマンド動作環境変数
su rootroot に切り替えるが、現在のシェル環境を引き継ぐ元のユーザーの PATH や HOME が残る
su – rootroot のログインシェルとして起動するroot の PATH、HOME、LANG などが設定される

su でハイフンを付け忘れると PATH が通らないことがある

su root では /sbin や /usr/sbin が PATH に含まれない場合があり、systemctlfirewall-cmd などの管理コマンドが「command not found」になることがあります。root に切り替える際は su - を使用してください。

su と sudo の比較

項目su –sudo コマンドsudo -i
必要なパスワードroot のパスワード自分のパスワード自分のパスワード
監査ログsu の実行のみ記録される実行したコマンドが記録されるシェル起動が記録される
権限の範囲root の全権限sudoers で許可されたコマンドのみroot の全権限

企業の運用では、sudo 経由での操作が推奨されます。理由は以下の 2 点です。

  • sudo は実行されたコマンドを /var/log/secure に記録するため、「誰が何を実行したか」を追跡できる
  • root パスワードを複数人で共有する必要がなく、パスワード漏洩のリスクを低減できる

9. アカウントのロック・無効化

退職者のアカウント停止や、セキュリティインシデント発生時のアカウント緊急ロックなど、アカウントを無効化する場面は頻繁にあります。方法によって無効化の範囲が異なるため、状況に応じて使い分ける必要があります。

passwd -l / usermod -L でパスワードをロックする

実行コマンド:

# passwd -l testlock

ロック状態を確認します。

実行コマンド:

# passwd -S testlock

実行結果:

testlock LK 2026-03-24 0 99999 7 -1 (パスワードはロック済み。)

LK はパスワードがロックされている状態を示します。その他のステータスは以下の通りです。

ステータス意味
PSパスワードが設定されている(通常の状態)
LKパスワードがロックされている
NPパスワードが設定されていない

passwd -u / usermod -U でアンロックする

実行コマンド:

# passwd -u testlock

usermod -Lusermod -U も同じ機能ですが、/etc/shadow のパスワードハッシュ先頭に ! を付加・除去する点は同一です。

パスワードロックだけでは SSH 鍵認証は止まらない

passwd -lusermod -L はパスワード認証をロックするだけです。SSH 公開鍵認証が設定されている場合、鍵認証によるログインは引き続き可能です。SSH 鍵認証も含めてログインを完全に禁止するには、ログインシェルを変更してください。

usermod -s /sbin/nologin でログインを完全に禁止する

ログインシェルを /sbin/nologin に変更すると、パスワード認証・鍵認証を問わず、対話的なログインが拒否されます。

実行コマンド:

# usermod -s /sbin/nologin testlock

切り戻し方法:

# usermod -s /bin/bash testlock

chage -E でアカウントの有効期限を設定する

契約期間が決まっている外部パートナーのアカウントには、あらかじめ有効期限を設定しておきます。

実行コマンド:

# chage -E 2026-06-30 testlock

2026年6月30日を過ぎると、このアカウントは自動的に無効化されます。

有効期限を解除する切り戻し方法:

# chage -E -1 testlock

10. システムアカウントとサービスアカウント

アプリケーションやデーモンプロセスを実行するための専用アカウントを「サービスアカウント」と呼びます。root でアプリケーションを実行すると、脆弱性を突かれた場合にシステム全体が侵害されるリスクがあるため、最小権限の原則に基づいて専用のアカウントで実行します。

サービスアカウントの作成

実行コマンド:

# useradd -r -s /sbin/nologin -d /opt/myapp -M myappsvc
オプション意味
-rシステムアカウントとして作成する(UID が 1000 未満になる)
-s /sbin/nologin対話的なログインを禁止する
-d /opt/myappホームディレクトリのパスを指定する(実際のディレクトリは作成しない)
-Mホームディレクトリを作成しない

作成結果を確認します。

実行コマンド:

$ id myappsvc

実行結果:

uid=995(myappsvc) gid=995(myappsvc) groups=995(myappsvc)

実行コマンド:

$ getent passwd myappsvc

実行結果:

myappsvc:x:995:995::/opt/myapp:/sbin/nologin

UID が 995(1000 未満)で割り当てられ、ログインシェルが /sbin/nologin に設定されていることが確認できます。

代表的なシステムアカウント

AlmaLinux 9 にデフォルトで作成されるシステムアカウントの一部を紹介します。

アカウント名用途
rootシステム管理者(UID 0)
nobody権限を持たないアカウント。NFS やプロセスの権限分離に使用される
apacheApache HTTP Server の実行ユーザー(httpd パッケージインストール時に作成)
sshdSSH デーモンの権限分離に使用されるアカウント
chronyNTP クライアント(chronyd)の実行ユーザー
polkitdPolicyKit 認可デーモンの実行ユーザー

11. umask によるデフォルトパーミッション

umask(user file-creation mode mask)は、新規ファイルやディレクトリを作成する際に「付与しないパーミッション」を指定する値です。

現在の umask 値を確認する

実行コマンド:

$ umask

実行結果:

0022

実行コマンド:

$ umask -S

実行結果:

u=rwx,g=rx,o=rx

umask -S はシンボリック形式で「結果的に付与されるパーミッション」を表示します。

umask の計算方法

ファイルとディレクトリではベースパーミッションが異なります。

対象ベースumask 0022 の場合結果
ファイル06660666 – 00220644(rw-r–r–)
ディレクトリ07770777 – 00220755(rwxr-xr-x)

AlmaLinux 9 のデフォルト umask は 0022 です。この設定では、新規ファイルは所有者が読み書き可能、グループとその他は読み取りのみです。

umask の設定箇所

umask はシェルの起動時に読み込まれる設定ファイルで定義します。

設定ファイル適用範囲
/etc/profile全ユーザーのログインシェル
/etc/bashrc全ユーザーの bash 起動時
~/.bashrc個別ユーザーの bash 起動時

企業セキュリティでの umask 変更

セキュリティ要件が厳しい環境では、umask を 0027 や 0077 に変更します。

umaskファイルディレクトリ用途
00220644(rw-r–r–)0755(rwxr-xr-x)デフォルト(一般的な共有環境)
00270640(rw-r—–)0750(rwxr-x—)その他ユーザーからの読み取りを禁止
00770600(rw——-)0700(rwx——)所有者のみアクセス可能(最も厳格)

全ユーザーに適用する場合は /etc/profile に記載します。

設定例:

umask 0027

切り戻し方法:該当行を umask 0022 に変更するか、行を削除してください。変更後、新しいシェルセッションから有効になります。

12. アカウントライフサイクル(企業運用チェックリスト)

企業でのアカウント管理は、入社から退職までのライフサイクル全体をカバーする運用設計が必要です。以下に、各フェーズで実施する作業をまとめます。

入社時

  1. UID 台帳から次の UID を払い出す
  2. useradd で UID を指定してアカウントを作成する
  3. 初期パスワードを設定し、chage -d 0 で初回ログイン時の変更を強制する
  4. 必要なグループに追加する(usermod -aG
  5. chage でパスワード有効期限を設定する

入社時のコマンド実行例:

# useradd -m -u 1002 -c 'Tanaka Taro' -s /bin/bash -G wheel tanaka
# passwd tanaka
# chage -d 0 -M 90 -W 14 -I 30 tanaka

異動時

  1. 新しい部署のグループに追加する(usermod -aG 新グループ ユーザー名
  2. 旧部署のグループから外す(gpasswd -d ユーザー名 旧グループ
  3. sudo 権限の見直し(/etc/sudoers.d/ の該当ファイルを修正)

グループからの除外コマンド:

# gpasswd -d tanaka old-team

退職時

  1. パスワードをロックする(passwd -l ユーザー名
  2. ログインシェルを変更する(usermod -s /sbin/nologin ユーザー名
  3. ホームディレクトリをバックアップする
  4. 一定期間(社内規定に従い 30〜90 日程度)経過後にアカウントを削除する

退職時のコマンド実行例:

# passwd -l tanaka
# usermod -s /sbin/nologin tanaka
# tar czf /backup/tanaka_home_$(date +%Y%m%d).tar.gz /home/tanaka

定期棚卸し(月次または四半期)

以下のコマンドを定期的に実行し、不要なアカウントや異常な状態がないか確認します。

確認項目コマンド
長期間ログインのないアカウントlastlog
孤立ファイルの有無find / -nouser -o -nogroup 2>/dev/null
パスワードのロック状態passwd -S ユーザー名
UID 一覧の確認getent passwd | awk -F: ‘{print $3,$1}’ | sort -n

13. トラブルシューティング

usermod -G でグループが消えた

症状usermod -G wheel testuser01 を実行した後、testuser01 が以前所属していたグループ(例:appteam、devteam)からすべて外れていた。

原因-G のみで -a(append)を付けなかったため、補助グループが指定したグループのみに上書きされた。

対処方法:元のグループをすべて指定して再設定する。

実行コマンド:

# usermod -aG wheel,appteam,devteam testuser01

予防策:グループ追加時は必ず usermod -aG を使用する。

userdel で「user is currently used by process」が表示される

症状userdel testuser01 を実行すると「userdel: user testuser01 is currently used by process XXXX」エラーが発生する。

原因:対象ユーザーが実行中のプロセスが存在する。ログインセッションが残っている、またはバックグラウンドプロセスが動作中の場合に発生する。

対処方法:対象ユーザーのプロセスを確認し、停止してから削除する。

実行コマンド:

# ps -u testuser01

プロセスを確認した後、対象プロセスを停止します。

実行コマンド:

# kill プロセスID

プロセス停止後に userdel を再実行してください。

sudoers の構文エラーで sudo が使えなくなった

症状:sudo を実行すると「syntax error」や「no valid sudoers sources found」が表示され、すべてのユーザーで sudo が使用不能になった。

原因:/etc/sudoers または /etc/sudoers.d/ 内のファイルに構文エラーがある。visudo を使わずに直接ファイルを編集した場合に発生する。

対処方法

  1. 別の TTY(端末)から root で直接ログインする(Ctrl+Alt+F2 など、物理コンソールまたは仮想コンソール)
  2. root でログイン後、visudo を実行して構文エラーを修正する
  3. リモート接続のみの環境で root ログインが無効な場合は、サーバーの管理コンソール(ILO、iDRAC、仮想マシンのコンソール)から root でログインする

実行コマンド(root でログイン後):

# visudo

sudoers の編集は必ず visudo 経由で行う

この問題を未然に防ぐため、/etc/sudoers および /etc/sudoers.d/ のファイルは、直接 vi で開かず、必ず visudo または visudo -f ファイルパス で編集してください。visudo は保存前に構文チェックを実行し、エラーがある場合は保存をキャンセルします。

パスワードをロックしたのに SSH ログインできてしまう

症状passwd -l でアカウントをロックしたが、対象ユーザーが SSH で引き続きログインできている。

原因passwd -l はパスワード認証のみをロックする。SSH 公開鍵認証(~/.ssh/authorized_keys)が設定されている場合、鍵認証によるログインはロックの対象外となる。

対処方法:ログインシェルを /sbin/nologin に変更して、すべての認証方式でログインを拒否する。

実行コマンド:

# usermod -s /sbin/nologin 対象ユーザー

SSH 鍵認証については、SSH設定編で詳しく解説しています。セキュリティ強化の全体像はセキュリティ強化編を参照してください。

AlmaLinux 9 総合リファレンスガイド シリーズ一覧

  1. システム基本情報の確認
  2. 初期設定
  3. ネットワーク設定(nmcli)
  4. パッケージ管理(dnf)
  5. ユーザー・グループ管理(この記事)
  6. ファイアウォール(firewalld)
  7. SSH設定・鍵認証
  8. systemd / サービス管理
  9. ストレージ・LVM
  10. ログ管理(journalctl / rsyslog)
  11. cron / systemd timer
  12. セキュリティ強化
  13. パフォーマンス監視
  14. コンテナ管理(Podman)
  15. バックアップ・リストア