午前2時のサーバー危機と/etc/passwdの脆弱性
午前2時、アラート音で目が覚めました。自動化スクリプトのミスで /etc/passwd が壊れ、本番サーバーがダウンしたのです。Linuxを管理している方なら、この断片化の恐ろしさをよくごじでしょう。ユーザーのアイデンティティは /etc/shadow、/etc/passwd、/etc/group に分散し、実際のデータは /home/user に存在します。これは40年前から続く、非常に壊れやすい設計です。
その夜の復旧作業は苦痛でした。5つの異なる設定ファイルにまたがるUIDとGIDを手動で整合させるのに3時間を費やしました。この経験から、フリート全体を systemd-homed に移行することを決意しました。メタデータを分散させる代わりに、ユーザーアカウントを単一の自己完結型オブジェクトとして扱います。ユーザーのホームディレクトリを新しいマシンに移動すれば、認証情報、暗号化キー、権限もすべて付随します。手動での同期は一切不要です。
クイックスタート：5分以内に管理ユーザーをデプロイする
導入は非常に簡単です。Arch、Fedora、Ubuntu 22.04+などの主要なディストリビューションにはパッケージが含まれていますが、デフォルトで有効になっていることは稀です。
# サービスのインストール (Ubuntu/Debianの例)
sudo apt update && sudo apt install systemd-homed
# デーモンを有効化して起動
sudo systemctl enable --now systemd-homedサービスが有効になれば、コマンド一つで安全に暗号化されたユーザーを作成できます。私は本番環境では、セキュリティとI/Oパフォーマンスのバランスが最も優れているLUKSバックエンドを使用しています。
# 5GBのクォータとLUKS暗号化を指定して 'devops' ユーザーを作成
sudo homectl create devops --storage=luks --disk-size=5Gこのコマンドにより、LUKS暗号化されたループバックファイル（通常は /home/devops.home）の作成、フォーマット、そしてユーザーのメタデータを含む署名済みJSONレコードの生成が自動的に行われます。詳細を確認するには、以下のコマンドを実行します。
homectl inspect devopsアーキテクチャ：なぜsystemd-homedは構造的に優れているのか
従来のLinuxユーザーは、システムに固定された存在でした。ホームディレクトリはディスク上に暗号化されずに置かれ、UIDはシステムの状態にハードコードされています。systemd-homedはこのライフサイクルを一変させます。ユーザーがログアウトすると、システムはディレクトリを暗号的にロックしてアンマウントします。OSは、ユーザーが再度認証するまでその存在を実質的に「忘れる」のです。
ストレージバックエンドの選択
ファイルシステムの構成に合わせて、主に4つの選択肢があります：
- LUKS: 業界標準。暗号化されたループバックファイルを作成するため、ext4やXFSに最適です。
- Subvolumes: Btrfsユーザーに最適。ネイティブのサブボリューム暗号化を利用します。
- fscrypt: カーネルレベルのファイルシステム暗号化で、オーバーヘッドを最小限に抑えます。
- Directory: 暗号化なしのプレーンなディレクトリ。レガシーなテスト用途にのみ使用してください。
4GBのRAMと40個の使い捨て開発者アカウントを持つテストノードでは、このアーキテクチャによりアカウントのプロビジョニング時間を70%削減できました。デーモンにマウントを任せることで、複雑な /etc/fstab の記述や、ピーク時にI/Oウェイトを発生させていた脆弱なクォータスクリプトを排除することができました。
このコマンドにより、LUKS暗号化されたループバックファイル（通常は /home/devops.home）の作成、フォーマット、そしてユーザーのメタデータを含む署名済みJSONレコードの生成が自動的に行われます。詳細を確認するには、以下のコマンドを実行します。LUKS暗号化されたループバックファイルを作成するため、ext4やXFSに最適です。
高度な管理：クォータとリソース制限
共有環境でのディスク容量管理は、通常は厄介な問題です。従来のクォータ管理では、移行時に壊れやすいファイルシステムレベルの調整が必要でした。
動的な制限
homectl を使えば、ボリュームをアンマウントすることなく、動的に制限を変更できます。’devops’ ユーザーが5GBの制限に達した場合、即座に倍増させることが可能です：
sudo homectl update devops --disk-size=10Gsystemd-homed は cgroups と統合されているため、CPUやメモリの制限（スロットリング）も可能です。これにより、暴走したPythonスクリプトがOOMキラーを誘発し、午前3時に基幹サービスをクラッシュさせるのを防ぐことができます。
sudo homectl update devops --tasks-max=500 --memory-high=2Gポータビリティの威力
ユーザーのアイデンティティは、暗号化ボリューム内の ~/.identity ファイルに保存されています。つまり、/home/devops.home を systemd-homed が動作している任意のサーバーに移動するだけで、新しいホストが即座にそのアカウントを認識します。ノード間でUIDを手動で合わせたり、/etc/shadow のハッシュをコピーしたりする必要はありません。
システム管理者のための実践的なトラブルシューティング
このスタックへの移行には、一般的な管理タスクの処理方法を変える必要があります。私たちの導入過程で得た教訓を共有します。
1. SSHキーのジレンマ
ホームディレクトリが暗号化されロックされている状態では、SSHデーモンは ~/.ssh/authorized_keys を読み取ることができません。これを回避するには、公開鍵をユーザーレコードに直接保存します：
homectl update devops --ssh-authorized-keys="ssh-rsa AAAA..."デーモンは認証時にこれらの鍵をSSHDに渡し、シームレスなパスワードレスログインを可能にしながら、ディスクのアンロックをトリガーします。
2. マウントの固着を解消する
セッションがハングすると、ホームディレクトリがマウントされたままになり、管理上の更新がブロックされることがあります。ロックを一度手動でかけ直すことで、状態をリセットできます：
sudo homectl lock devops
sudo homectl unlock devops3. デスクトップ環境との互換性
GUIユーザーの場合、ディスプレイマネージャー（GDM、SDDM、またはLightDM）が pam_systemd_home を使用するように設定されているか確認してください。このモジュールがないと、認証には成功してもディスクのアンロックに失敗し、不完全なセッションや汎用的な一時ホームフォルダが作成される原因となります。
systemd-homed への切り替えは、手動設定からモダンなAPIへの移行のように感じられました。考え方の転換が必要ですが、セキュリティとポータビリティのメリットは否定できません。次にサーバーにトラブルが発生したときは、.home ファイルを移動させるだけで済みます。/etc/passwd の混乱に悩まされることはもうありません。
