はじめに
Ansibleの検証環境として、VirtualBox上に管理サーバ1台と管理対象サーバ3台を用意しました。
前回は、Ubuntu 24.04のHost-Only側に固定IPを設定し、controllerから3台へpingが通るところまで確認しました。
今回の構成は次のとおりです。
| ホスト名 | 役割 | IPアドレス |
|---|---|---|
| controller | 管理サーバ | 192.168.56.10 |
| tokyo | 東京店サーバ | 192.168.56.11 |
| yokohama | 横浜店サーバ | 192.168.56.12 |
| omiya | 大宮店サーバ | 192.168.56.13 |
今回は、このcontrollerから3台へSSH接続し、
パスワード入力なしでSSHできる状態
まで確認します。
実際に確認した流れは次のとおりです。
通常のSSH接続を確認
↓
controllerのSSH鍵を確認
↓
ssh-copy-idで公開鍵の登録状態を確認
↓
authorized_keysを確認
↓
BatchMode=yesでパスワードなしSSHを確認
まず通常のSSH接続を確認する
いきなり公開鍵認証を確認するのではなく、まずcontrollerから各サーバへ通常のSSH接続ができることを確認しました。
tokyo：
ssh tokyo@192.168.56.11
yokohama：
ssh yokohama@192.168.56.12
omiya：
ssh omiya@192.168.56.13
今回の環境では、3台すべてへSSH接続できることを確認しました。
先に通常のSSH接続を確認したのは、問題が発生したときに切り分けやすくするためです。
例えば公開鍵認証で接続できなかった場合、
そもそもSSH接続できない
のか、
SSH接続はできるが、公開鍵認証に問題がある
のかでは、確認する場所が変わります。
そのため今回は、
ping
↓
通常のSSH
↓
SSH公開鍵認証
という順番で確認しました。
なぜSSH公開鍵認証を使うのか
通常のSSH接続はできました。
ただし、これからAnsibleを使って複数台のLinuxサーバをまとめて操作することを考えています。
そのとき、
controller
↓
tokyo
↓
パスワード入力
controller
↓
yokohama
↓
パスワード入力
controller
↓
omiya
↓
パスワード入力
と毎回パスワードを入力するのは、自動化するうえでは少し面倒です。
そこでSSH公開鍵認証を利用します。
今回の構成を簡単に表すと、次のようになります。
controller
│
├─ 秘密鍵を保管
│
├────→ tokyo
│ └─ 公開鍵を登録
│
├────→ yokohama
│ └─ 公開鍵を登録
│
└────→ omiya
└─ 公開鍵を登録
接続元であるcontrollerで秘密鍵を管理し、接続先となる各サーバへ公開鍵を登録します。
ここで重要なのは、
秘密鍵をtokyo・yokohama・omiyaへコピーするわけではない
という点です。
controllerにあるSSH鍵を確認する
私の環境では、SSH鍵はすでに作成済みでした。
そのため、今回の検証のためにSSH鍵を新しく作り直してはいません。
controllerで次のコマンドを実行しました。
ls -la ~/.ssh/
これで、現在使用しているSSH関連ファイルを確認します。
一般的にSSH鍵を新しく作成する場合は、
ssh-keygen
を使用できます。
ただし、今回は実際にssh-keygenを実行して新しい鍵を作成したわけではないため、この記事では鍵生成の手順については扱いません。
ssh-copy-idで公開鍵の登録状態を確認する
公開鍵を接続先サーバへ登録する方法の一つとして、ssh-copy-idがあります。
今回の環境では、次のコマンドを実行しました。
tokyo：
ssh-copy-id tokyo@192.168.56.11
yokohama：
ssh-copy-id yokohama@192.168.56.12
omiya：
ssh-copy-id omiya@192.168.56.13
すると、今回の環境では次のメッセージが表示されました。
All keys were skipped because they already exist on the remote system.
これは、公開鍵がすでに接続先に存在しているため、追加がスキップされたことを示しています。
今回の環境では、以前の検証ですでに公開鍵を登録していました。
そのため、記事を書くためだけに公開鍵を削除して再登録することはせず、現在の環境で登録状態を確認することにしました。
authorized_keysを確認する
次に、接続先サーバで公開鍵が登録されていることを確認します。
ls -l ~/.ssh/authorized_keys
さらに、
wc -l ~/.ssh/authorized_keys
を実行しました。
今回の環境では、
1
と表示されました。
tokyo・yokohama・omiyaの3台すべてで確認し、それぞれauthorized_keysに1行ある状態でした。
これで、
controller
↓
公開鍵
↓
各サーバのauthorized_keys
という状態になっていることを確認できました。
ただし、ここで一つ気になりました。
authorized_keysに公開鍵があるだけで、本当にパスワードなしで接続できると言えるのか？
そこで最後に、実際のSSH接続でも確認します。
BatchMode=yesでパスワードなしSSHを確認する
今回はBatchMode=yesを指定してSSH接続を試しました。
tokyo：
ssh -o BatchMode=yes tokyo@192.168.56.11 'hostname'
yokohama：
ssh -o BatchMode=yes yokohama@192.168.56.12 'hostname'
omiya：
ssh -o BatchMode=yes omiya@192.168.56.13 'hostname'
BatchMode=yesを指定すると、パスワード入力などの対話的な認証を行わずにSSH接続を試すことができます。
また、今回のコマンドではSSH接続後に、
hostname
を実行しています。
そのため、接続できれば各サーバのホスト名が返ってきます。
今回の環境では、
tokyo
yokohama
omiya
と、それぞれのホスト名が返ってきました。
これで3台とも、パスワード入力なしでSSH接続できることを確認できました。
なぜBatchMode=yesで確認したのか
普通に、
ssh tokyo@192.168.56.11
と接続して確認することもできます。
ただ、今回確認したかったのは、
「SSHできるか」だけではなく、「対話的なパスワード入力なしでSSHできるか」
という点です。
そのため、
通常のSSH接続
↓
公開鍵の登録状態
↓
authorized_keys
↓
BatchMode=yesによる実際の接続
という順番で確認しました。
authorized_keysが存在することだけで終わらせず、最後に実際の接続まで確認することで、Ansibleを使う前のSSH環境が整っていることを確認できました。
Ansibleを使う前にSSHを確認しておく
今回、Ansibleを実行する前にSSHだけでここまで確認しました。
理由は、今後Ansibleで接続できない問題が発生した場合に、確認する場所を絞りやすくするためです。
例えば、
pingできない
↓
ネットワークやIPアドレスを確認
pingできるがSSHできない
↓
SSH側を確認
SSHできるがAnsibleから接続できない
↓
Ansible側の設定を確認
というように、一つずつ切り分けられます。
実際に環境を作ってみると、Ansibleだけが単独で動いているわけではなく、
ネットワーク
↓
IPアドレス
↓
SSH
↓
SSH公開鍵認証
↓
Ansible
という土台の上にあることが分かりました。
まとめ
今回は、controllerから3台のUbuntuサーバへSSH公開鍵認証で接続できることを確認しました。
実際に確認した流れは、
通常のSSH接続
↓
controllerのSSH鍵を確認
↓
ssh-copy-idを実行
↓
公開鍵がすでに登録済みであることを確認
↓
authorized_keysを確認
↓
BatchMode=yesで実際の接続を確認
です。
最終的に、
controller
│
│ SSH公開鍵認証
│
├── tokyo OK
├── yokohama OK
└── omiya OK
となり、3台ともパスワード入力なしでSSH接続できることを確認しました。
これで、Ansibleから複数台のLinuxサーバを操作するためのSSH環境が整いました。
次回は今回までの検証をもとに、
「Ansibleで接続できないとき、どこから確認すればいいのか」
という視点で、ネットワーク・IPアドレス・SSH・公開鍵認証の切り分け方を整理します。
一連の検証を最初から読みたい
noteでは、Linux・Ansibleを実際に触りながら、「なぜこの設定が必要なのか」も含めて、検証の流れをまとめています。
今回のSSH設定だけではなく、複数台のLinuxサーバを用意したところから一連の流れを読みたい方はこちらです。
note
https://note.com/yuki_jo_323
Xでは、記事になる前の実機検証や、作業中に発生した失敗、調べて分かったことなども投稿しています。
Linux・Ansible・Python・Excelなどを使った検証を続けているので、「この環境で次に何をやるのか見てみたい」という方はこちらからどうぞ。
GitHubでは、実際の検証で作成したPlaybookやPythonスクリプトなどを公開しています。
GitHub