古い鍵を安全に削除する

はじめに

Ava はスタジオの古いノートパソコンを交換しました。両ホストは現在と予備の鍵に加え、古い端末の鍵もまだ受け付けています。アカウントと元のメモを保ち、古い端末の許可だけを取り除きます。

この独立単元は「同僚にアクセスを許可する」のユーザー、公開鍵、lookup、ループの練習を前提とします。独自の練習鍵と既存アカウントは準備済みで、前の VM のファイルや接続は引き継ぎません。

古い端末の鍵を1本削除する

このステップでは両スタジオホストで Ava の古い端末の鍵を失効させ、新規接続が拒否されることを証明し、現在の鍵、予備の鍵と元の作業を保ちます。

この単元には独自の新しい環境があります。Ava はすでに両対象にアカウントと作業を持っています。各アカウントは現在、予備、古い端末の 3 本の練習鍵を受け付けます。古い許可だけを削除します。鍵の削除はそれによる新しい認証を阻止しますが、認証済みの接続を終了しません。この実習は新規接続を試し、セッション終了を保証するものではありません。

Controller を開いてプロジェクトへ移動します。誤って別のディレクトリーへ移動した場合もこのコマンドで戻れます。

cd /home/labex/project

準備済みの入力とクライアント別名を読みます。

cat approved-staff.json

cat clients.conf

承認アカウントは studio_ava です。失効させる鍵は training-keys/ava-old.pub で、training-keys/ava.pub と training-keys/ava-backup.pub は許可を維持します。.pub で終わる鍵は公開鍵で、対応する秘密鍵は練習クライアントに残ります。別名はホスト、ユーザーと正確な鍵を選びます。-F clients.conf は信頼を固定したこのプロジェクト設定を使い、各 ssh 呼び出しが新しい接続を作ります。インベントリー、クライアント設定、ホストの信頼と練習鍵を変えないでください。

アクセス変更前に正常動作を観察します。単一引用符内のリモートシェルは、セミコロンで区切った id と cat を順に実行します。

ssh -F clients.conf web1-ava 'id -un; cat work/briefing.txt'

ssh -F clients.conf web2-ava 'id -un; cat work/briefing.txt'

どちらも身元は studio_ava ですが、Riverside と Hill のメモは異なります。予備の鍵も確認します。

ssh -F clients.conf web1-ava-backup 'id -un'

ssh -F clients.conf web2-ava-backup 'id -un'

この時点では古い端末もまだ許可されています。

ssh -F clients.conf web1-ava-old 'id -un'

ssh -F clients.conf web2-ava-old 'id -un'

追加する鍵の一覧から 1 本を消すだけでは、対象からの削除を要求したことになりません。空の追加一覧でこの違いを安全に見ます。here-document はコントローラーのファイル全体を書きます。> が置き換え、引用した YAML がシェル展開を防ぎます。終了区切り文字は行頭に単独で置きます。終了区切り文字がなくシェルが待っていたら、Ctrl+C で未完了入力を取り消し、通常のプロンプトから全ブロックを再実行します。空の YAML リスト [] をループしても、処理する項目はありません。

cat > additions.yml <<'YAML'
- name: Add listed keys without removing other grants
  hosts: all
  become: true
  gather_facts: false
  vars:
    keys_to_add: []
  tasks:
    - name: Add a listed key
      ansible.posix.authorized_key:
        user: studio_ava
        key: "{{ lookup('file', item) }}"
        state: present
      loop: "{{ keys_to_add }}"
YAML

ansible-playbook additions.yml

両ホストで鍵タスクがスキップされ、変更はありません。すべての許可を調べて一覧にない鍵を削除したわけではありません。古い端末は引き続き接続できます。

ssh -F clients.conf web1-ava-old 'id -un'

ここで実際の失効を表現します。group_vars/all.yml は両インベントリーホストへこの一覧を提供し、準備済みの承認ファイルは変えません。各オブジェクトはコースユーザーとコントローラー上の公開鍵パスを示します。不正なファイルブロックは再実行してそのコントローラーファイルを置き換えられ、VM のリセットは不要です。

cat > group_vars/all.yml <<'YAML'
revoked_keys:
  - name: studio_ava
    key_file: training-keys/ava-old.pub
YAML

学んだ鍵モジュールと state: absent を使い、アカウントとほかの許可を保ってこの鍵を削除します。ループは列挙した各削除を処理します。二重の波括弧は現在の項目を解決し、lookup はコントローラー上の公開鍵を読みます。コレクションは本プロジェクト用にオフライン導入済みです。排他的な置換、ホームの削除、パスワードのロック、プラットフォームの SSH サービス変更はしないでください。

cat > revoke.yml <<'YAML'
- name: Revoke only the approved old device keys
  hosts: all
  become: true
  gather_facts: false
  tasks:
    - name: Remove each listed old public key
      ansible.posix.authorized_key:
        user: "{{ item.name }}"
        key: "{{ lookup('file', item.key_file) }}"
        state: absent
      loop: "{{ revoked_keys }}"
YAML

構文を確認します。YAML エラーでは指定行を読み、完全なブロックと字下げや引用符を比較し、そのコントローラーファイルだけを書き直します。

ansible-playbook revoke.yml --syntax-check

これらのアカウントはすでに存在するため、対応する check mode で鍵の削除を予測できます。--diff は公開鍵の行も表示しますが、今回の予測には不要です。--check を使います。

ansible-playbook revoke.yml --check

両ホストとも変更を予測するはずです。check mode はまだ実際の許可を失効させていません。適用します。

ansible-playbook revoke.yml

両ホストとも接続不能や失敗したタスクがなく完了する必要があります。次の 2 接続は Permission denied (publickey)、終了ステータス 255 で失敗する想定です。

ssh -F clients.conf web1-ava-old 'id -un'

ssh -F clients.conf web2-ava-old 'id -un'

タイムアウト、接続拒否やホスト鍵の警告は失効の証明になりません。サーバーは利用でき、許可した鍵は引き続き使える必要があります。現在と予備の鍵で新規接続し、両方の元のファイルを読みます。

ssh -F clients.conf web1-ava 'id -un; cat work/briefing.txt'

ssh -F clients.conf web2-ava 'id -un; cat work/briefing.txt'

ssh -F clients.conf web1-ava-backup 'id -un; cat work/briefing.txt'

ssh -F clients.conf web2-ava-backup 'id -un; cat work/briefing.txt'

4 回とも studio_ava として成功し、対応する元のメモを表示しなければなりません。バイト列、所有者、モード 0640 を保ち、ホーム/作業ディレクトリーを 0750、.ssh を 0700、authorized_keys を 0600 のままにします。ファイルは studio_ava とそのプライマリーグループの所有です。既存の鍵モジュールはこれらの準備済みの安全な権限を保ちます。

実際の宣言を繰り返してから予測します。

ansible-playbook revoke.yml

ansible-playbook revoke.yml --check

両要約は changed=0、unreachable=0、failed=0 を表示するはずです。正しい失効は実際の許可の選択的な変更であり、成功要約や空のコントローラー一覧だけではありません。誤った鍵パスを選んだ場合はコントローラーデータを直します。以前学んだ state: present で誤削除した正当な鍵を復元し、正しい選択的削除を再適用します。鍵ファイル全体を空にしたり全員書き込み可能にしたりして復旧しないでください。

まとめ

追加の省略と明示的な失効を区別し、state absent で公開鍵の許可を 1 つ削除しました。実際の新規接続拒否を確認し、現在と予備のログインおよび両方の元の作業ファイルを維持しました。変更しない宣言は無駄な変更なく収束しました。