一台ずつSSHで接続して `useradd` を実行し、公開鍵を `~/.ssh/authorized_keys` にコピーする——この作業を手作業で繰り返すと、「あのサーバーだけUID番号が違う」「1台だけ鍵の登録を忘れた」「退職したメンバーの鍵がどこかに残っている」という問題が必ず起きます。
この記事では、Ansibleの `user` モジュールと `authorized_key` モジュールを組み合わせ、複数サーバーのユーザーアカウントと公開鍵を一括管理する設計を解説します。ansible-playbookの単体コマンド解説ではなく、インベントリ設計・変数管理・ロール設計という統制の視点でまとめています。
「ansible user 公開鍵 一括管理」を実現したいエンジニアはぜひ参考にしてください。
動作確認環境：RHEL 9.4 / Rocky Linux 9.4 / Ubuntu 22.04 LTS（Ansible 2.16）
この記事のポイント
・userモジュールで全台のアカウントをPlaybookで宣言管理できる
・exclusive: trueで古い公開鍵を全台から自動削除できる
・group_varsでユーザーリストを変数化すると1ファイルで全台管理できる
・Roleに切り出すことでユーザー管理設計を複数環境に再利用できる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
手作業ユーザー管理が抱える3つのリスク
複数台のサーバーを手作業で管理し続けると、次の3つの問題が積み重なります。UID不整合：サーバーごとに `useradd` を実行すると、既存ユーザーの状況によってUIDが自動採番されます。NFS共有ディレクトリを使う環境では、UID不一致が「ファイルの所有者が解決できない」トラブルに直結します。
公開鍵の残存：退職したメンバーの公開鍵が複数台のサーバーに残り続けます。「全台削除した」つもりでも、手作業では1台の漏れが起きやすく、監査や証跡確認のコストも高くなります。
設定のドリフト：「このサーバーだけ設定が違う」という状態が気づかないうちに蓄積します。インシデント対応や監査の場面で「どれが正しい状態か分からない」という混乱を招きます。
Ansibleでユーザー管理を統制する本質的なメリットは、誰がどのサーバーにアクセスできるかをコードで記録・管理できることです。Playbookを読めば「あるべき状態」が一目で確認できます。
Ansible userモジュールの設計
`ansible.builtin.user` モジュールは、Linuxユーザーの作成・変更・削除をべき等に実行します。何度実行しても、Playbookに記述した「あるべき状態」を維持します。1. ユーザー作成の基本Playbook
最小構成のユーザー作成タスクから見ていきます。--- # site.yml — ユーザー管理Playbook - name: ユーザーアカウントを管理する hosts: webservers become: true tasks: - name: アプリ運用ユーザーを作成する ansible.builtin.user: name: appuser uid: 2001 group: appuser shell: /bin/bash state: present create_home: true
PLAY [ユーザーアカウントを管理する] *********************************** TASK [Gathering Facts] ************************************* ok: [web01.example.internal] ok: [web02.example.internal] ok: [web03.example.internal] TASK [アプリ運用ユーザーを作成する] ********************************* changed: [web01.example.internal] changed: [web02.example.internal] changed: [web03.example.internal] PLAY RECAP ************************************* web01.example.internal : ok=2 changed=1 unreachable=0 failed=0 web02.example.internal : ok=2 changed=1 unreachable=0 failed=0 web03.example.internal : ok=2 changed=1 unreachable=0 failed=0
2. state: absentによる削除設計
退職者のアカウント削除は `state: absent` で行います。- name: 退職者アカウントを全台から削除する ansible.builtin.user: name: oldmember state: absent remove: true # ホームディレクトリも合わせて削除する force: true # プロセスが残っている場合も削除を続行する
3. uidとshellを明示することの重要性
複数台環境では `uid` の明示指定が鉄則です。省略すると、サーバーごとの既存ユーザー状況によって異なるUIDが自動採番されます。・uid：全サーバーで統一する（例：2001～2099を運用ユーザー帯域として確保）
・shell：/bin/bash（通常ログインユーザー）か /sbin/nologin（サービスアカウント）を明示する
・groups：追加グループが必要な場合は groups リストで指定し append: true を組み合わせる
authorized_keyモジュールで公開鍵を一括配布する
`ansible.posix.authorized_key` モジュールは `~/.ssh/authorized_keys` の内容を管理します。ユーザー作成と公開鍵配布を同じPlaybookで行うことで、ansible user 公開鍵 一括管理の仕組みが完成します。1. authorized_keyモジュールの基本
公開鍵をファイルから読み込んで登録するタスクは次のとおりです。- name: SSH公開鍵を登録する ansible.posix.authorized_key: user: appuser key: "{{ lookup('file', 'files/appuser.pub') }}" state: present
2. exclusive: trueで古い公開鍵を自動削除する
`exclusive: true` を指定すると、`key` パラメータで指定した鍵以外をすべて `authorized_keys` から削除します。退職者の鍵が残り続けるリスクを排除できます。- name: SSH公開鍵を登録する（不要な鍵は自動削除） ansible.posix.authorized_key: user: appuser key: "{{ lookup('file', 'files/appuser.pub') }}" state: present exclusive: true # このキー以外はauthorized_keysから削除される
3. loopで複数ユーザーの鍵を一括処理する
ユーザーリストを変数化してループ処理することで、ユーザーが増えてもタスクの変更なしに対応できます。- name: 複数ユーザーの公開鍵を一括配布する ansible.posix.authorized_key: user: "{{ item.name }}" key: "{{ lookup('file', 'files/' + item.name + '.pub') }}" state: present exclusive: true loop: "{{ managed_users }}" when: item.state | default('present') == 'present'
Ansibleハンズオン講座はこちら
「RHEL環境でAnsibleを実際に動かしてみたい」方には、Linux Master Pro Seminarのハンズオン講座がおすすめです。
userモジュール・authorized_keyモジュールを含む実践的なPlaybook設計を少人数で体験できます。
＞＞ Ansibleハンズオン講座の詳細を見る
インベントリとロール設計の視点
userモジュールとauthorized_keyモジュールの使い方を理解したら、次は「どこに何を書くか」という設計の視点に移ります。1. インベントリのグループ設計で適用範囲を制御する
どのサーバーにユーザー管理を適用するかは、インベントリのグループで制御します。# inventory/hosts.ini [webservers] web01.example.internal ansible_user=ansible web02.example.internal ansible_user=ansible web03.example.internal ansible_user=ansible [dbservers] db01.example.internal ansible_user=ansible db02.example.internal ansible_user=ansible # 全台を対象とするグループ [managed:children] webservers dbservers
2. group_varsでユーザーリストを変数化する
ユーザーリストをPlaybookに直書きせず、`group_vars` に切り出します。# group_vars/all.yml managed_users: - name: appuser uid: 2001 shell: /bin/bash state: present - name: deploy uid: 2002 shell: /bin/bash state: present - name: oldmember uid: 2003 state: absent # 退職者：この1行を変えるだけで全台から削除される
3. Roleに切り出して再利用可能にする
Roleに切り出すと、別のプロジェクトや本番・ステージング・開発の複数環境で同じユーザー管理設計を再利用できます。roles/ └── user_management/ ├── defaults/ │ └── main.yml # managed_usersのデフォルト値 ├── tasks/ │ └── main.yml # user/authorized_keyタスク └── files/ ├── appuser.pub # 公開鍵ファイル └── deploy.pub # 公開鍵ファイル
--- - name: ユーザー管理を全台に適用する hosts: managed become: true roles: - role: user_management
トラブルシュート：よくある失敗パターンと対処
「UNREACHABLE」エラーが出る場合
Ansibleが接続先サーバーに到達できない場合は、まずSSHの接続確認から始めます。# 自分のPCからSSH接続テストを行う ssh -v ansible@web01.example.internal -p 22 # 接続先サーバーでSSHポートが開いているか確認する ss -tlnp | grep :22
「Permission denied (publickey)」が出る場合
自分のPCの秘密鍵と、対象サーバーの `~/.ssh/authorized_keys` に登録された公開鍵が一致していないことが原因です。# 対象サーバー上でパーミッションを確認する ls -la ~/.ssh/ # 正しいパーミッションの例 # drwx------ 2 appuser appuser ... .ssh # -rw------- 1 appuser appuser ... authorized_keys
UIDが既存ユーザーと衝突する場合
`uid` で指定した値が既存ユーザーと重複するとエラーが返ります。事前にUID使用状況を確認します。# 現在割り当てられているUID一覧を確認する awk -F: '{print $3, $1}' /etc/passwd | sort -n | tail -20
本記事のまとめ
Ansibleを使ったユーザーアカウントと公開鍵の一括管理を表にまとめます。| やりたいこと | Ansibleでの対応 |
|---|---|
| 複数台へのユーザー作成 | ansible.builtin.user state: present |
| 退職者アカウントの全台削除 | ansible.builtin.user state: absent, remove: true |
| SSH公開鍵の一括配布 | ansible.posix.authorized_key state: present |
| 古い公開鍵の自動削除 | ansible.posix.authorized_key exclusive: true |
| UID不整合の防止 | ansible.builtin.user uid: 2001（明示固定） |
| ユーザーリストの一元管理 | group_vars/all.yml の managed_users 変数 |
| 設計の再利用 | user_management ロールへの切り出し |
手作業のユーザー管理が引き起こす「UID不整合」「公開鍵の残存」「設定のドリフト」は、Ansibleのuser/authorized_keyモジュールと適切な変数管理で解消できます。
「ansible user 公開鍵 一括管理」の実践において、最初の一歩はユーザーリストの変数化（group_vars/all.yml）から始めることをおすすめします。1つのファイルを編集するだけで全台の設定が揃う体験が、Ansibleによる統制設計の本質を実感させてくれます。
実機でRoleを使ったPlaybook設計を体験したい方は、Ansibleハンズオン講座（ansible.linuxmaster.jp）でRHEL対応の少人数ハンズオン形式で学べます。ぜひ詳細をご覧ください。
Linux無料マニュアルを受け取る ＞＞
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：AWX入門｜AnsibleをGUIで運用する方法とジョブテンプレート・スケジュール実行の構築手順
- 前のページへ：Ansibleのdelegate_toとrun_onceの使い方｜ロードバランサー操作を含むオーケストレーション設計
- この記事の属するカテゴリ：Ansibleへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます