はじめに
管理対象ノードへのアクセスは、Ansible 自動化の基盤です。実際の環境では、Ansible は通常 SSH 経由で接続し、管理タスクの実行には特権昇格（privilege escalation）を使用します。
この実験では、使い捨ての管理対象ユーザー rhce_node を作成します。SSH キーを生成し、そのユーザーに対して認証を設定し、インベントリを構成した上で、通常の SSH 実行と become によるアクセス権限の両方を検証します。
SSH 練習用プロジェクトの作成
このステップでは、プロジェクトディレクトリを作成し、SSH ベースのアクセスに必要な Ansible のデフォルト設定を行います。管理用アカウントは既に存在しますが、まだあなたのキーを信頼していません。
プロジェクトを作成し、ディレクトリに移動します。
cd /home/labex/project
mkdir -p rhce-ansible/{inventory,keys,playbooks}
cd rhce-ansible
ansible.cfg を作成します。
cat > ansible.cfg <<'EOF'
[defaults]
inventory = ./inventory/hosts
host_key_checking = False
retry_files_enabled = False
interpreter_python = auto_silent
EOF
このプロジェクトでは、後のステップで 127.0.0.1 への実際の SSH 接続を使用します。keys ディレクトリは、実験用のキーペアを通常の ~/.ssh ファイルと分離するために使用します。また、host_key_checking = False を設定することで、このローカル環境での演習中にインタラクティブなプロンプトが表示されるのを防ぎます。
SSH キーペアの生成
このステップでは、Ed25519 SSH キーペアを作成します。秘密鍵は keys/rhce_ed25519 に保持し、公開鍵は管理対象アカウントにインストールします。-N '' オプションを使用することで、実験の自動化のためにパスフレーズなしのキーを作成します。
このステップのコマンドを実行する前に、Ansible プロジェクトディレクトリに戻ってください。これにより、LabEx が各ステップを個別に実行する場合でもコマンドが安定します。
cd /home/labex/project/rhce-ansible
キーペアを生成します。
ssh-keygen -t ed25519 -f keys/rhce_ed25519 -N '' -C rhce-ansible-lab
これにより 2 つのファイルが作成されます。keys/rhce_ed25519 は秘密鍵であり、厳重に管理する必要があります。keys/rhce_ed25519.pub は公開鍵であり、管理対象ユーザーのアカウントにインストール可能です。
公開鍵の内容を確認します。
cat keys/rhce_ed25519.pub
公開鍵の行は ssh-ed25519 で始まり、コメント rhce-ansible-lab で終わるはずです。authorized_keys にコピーするのは、秘密鍵ではなくこの公開鍵です。
管理対象ユーザーへのキー認証設定
このステップでは、使い捨ての管理対象ユーザーのために公開鍵をインストールします。ここでは labex ユーザーの SSH アクセス設定を変更するのではなく、この実験のために rhce_node を準備します。
このステップのコマンドを実行する前に、Ansible プロジェクトディレクトリに戻ってください。
cd /home/labex/project/rhce-ansible
管理対象ユーザーの .ssh ディレクトリを作成します。
sudo mkdir -p /home/rhce_node/.ssh
SSH は、ユーザーの .ssh ディレクトリ内にある信頼された公開鍵を参照します。このディレクトリは別のユーザーのホームディレクトリ配下にあるため、sudo が必要です。
公開鍵を authorized_keys としてインストールします。
sudo cp keys/rhce_ed25519.pub /home/rhce_node/.ssh/authorized_keys
所有権とパーミッションを修正します。ディレクトリやファイルの権限が緩すぎると、SSH はキーの使用を拒否します。
sudo chown -R rhce_node:rhce_node /home/rhce_node/.ssh
sudo chmod 700 /home/rhce_node/.ssh
sudo chmod 600 /home/rhce_node/.ssh/authorized_keys
これらのパーミッション値は意図的なものです。700 は rhce_node だけが .ssh ディレクトリにアクセスできるようにし、600 はそのユーザーだけが authorized_keys を読み書きできるようにします。これらのチェックにより、ログイン情報の意図しない漏洩を防ぎます。
SSH アクセス用インベントリの構成
このステップでは、Ansible に対してローカルホスト上の管理対象ユーザーへ SSH で接続する方法を指示するインベントリを作成します。
このステップのコマンドを実行する前に、Ansible プロジェクトディレクトリに戻ってください。
cd /home/labex/project/rhce-ansible
インベントリを記述します。
cat > inventory/hosts <<'EOF'
[managed]
node1 ansible_host=127.0.0.1 ansible_user=rhce_node ansible_ssh_private_key_file=/home/labex/project/rhce-ansible/keys/rhce_ed25519
EOF
このインベントリ行は、Ansible の名前と接続詳細を分離しています。node1 はインベントリのエイリアス、ansible_host は接続先アドレス、ansible_user はリモートアカウント、ansible_ssh_private_key_file は秘密鍵の場所を指します。
Ansible を使用する前に、SSH で直接テストします。
ssh -i keys/rhce_ed25519 -o StrictHostKeyChecking=no rhce_node@127.0.0.1 'whoami'
コマンドの結果として rhce_node が表示されるはずです。
SSH で直接テストを行うことで、後で Ansible が失敗した場合の問題の切り分けが容易になります。直接 SSH でログインできない場合は、Ansible モジュールのトラブルシューティングを行う前に、キー、所有権、パーミッション、またはインベントリの接続設定を修正してください。
Ansible Ping と Become の検証
このステップでは、Ansible の接続性と特権昇格をテストします。-b オプションは become を意味し、Ansible に対して昇格した権限でモジュールを実行するよう指示します。
このステップのコマンドを実行する前に、Ansible プロジェクトディレクトリに戻ってください。
cd /home/labex/project/rhce-ansible
SSH 経由で Ansible の ping モジュールを実行します。
ansible managed -m ansible.builtin.ping
今回は ping モジュールがローカル接続のショートカットを使用していません。Ansible は rhce_node として接続し、小さなモジュールを転送して Python で実行し、pong を返します。
特権昇格を伴うコマンドを実行します。id -u コマンドは、root として実行されると 0 を返します。
ansible managed -b -m ansible.builtin.command -a 'id -u'
-b フラグはこのコマンドに対して become を有効にします。結果に 0 が含まれていれば、管理対象ユーザーがこの実験用に作成された sudoers ルールを通じて昇格できることが証明されます。
Ansible の become を使用して、root 所有の証明ファイルを作成します。
ansible managed -b -m ansible.builtin.copy -a 'content=become_ready dest=/etc/rhce-ansible-become.txt mode=0644'
/etc 配下への書き込みには管理者権限が必要なため、この最後のコマンドは単なる接続以上のことを証明します。Ansible が SSH 経由で接続できるだけでなく、要求に応じて特権的なシステム変更を実行できることを確認しました。
まとめ
SSH キーペアを生成し、使い捨ての管理対象ユーザーに対して認証を設定し、SSH ベースのインベントリアクセスを構成しました。さらに、Ansible の become を使用して特権昇格の検証を行いました。
