StrictHostKeyCheckingとは？SSH接続時のホスト鍵検証の仕組みを解説
KoAN
目次
StrictHostKeyCheckingの役割と安全なSSH接続の仕組みを理解しよう
SSHを利用してLinuxサーバへ接続していると、初回接続時にホスト鍵の確認メッセージが表示されます。
この動作に関係しているのがStrictHostKeyCheckingという設定です。
実務では自動化スクリプトやAnsible、CI/CD環境などでSSHを利用する機会が増えており、StrictHostKeyCheckingの設定を変更する場面も少なくありません。
しかし、設定内容を理解せずに「StrictHostKeyChecking no」を利用すると、SSH本来のセキュリティ機能を無効化してしまう可能性があります。
本記事ではStrictHostKeyCheckingの役割や動作、設定方法、実務での利用時の注意点について詳しく解説します。
StrictHostKeyCheckingとは
StrictHostKeyCheckingとは、SSHクライアントが接続先サーバのホスト鍵をどのように検証するかを制御する設定です。
SSHでは接続先サーバが本物であることを確認するためにホスト鍵を利用します。
その確認処理の動作を制御するのがStrictHostKeyCheckingです。
設定はSSHクライアント側で行います。
なぜホスト鍵の確認が必要なのか
SSHでは通信の暗号化だけでなく、接続先サーバが本物であることも重要です。
もし攻撃者が偽のSSHサーバを用意し、本来のサーバになりすました場合、利用者は認証情報を盗まれる可能性があります。
このような攻撃を中間者攻撃（Man in the Middle Attack）と呼びます。
SSHはホスト鍵によって接続先サーバを検証し、この攻撃を防止しています。
ホスト鍵とは何か
SSHサーバにはホスト鍵と呼ばれる鍵ペアが存在します。
一般的には以下の場所に保存されています。
/etc/ssh/
例です。
ssh_host_ed25519_key
ssh_host_ed25519_key.pubこの鍵はサーバ自身を識別するために利用されます。
利用者認証に利用する公開鍵とは別のものです。
初回接続時の動作
SSHで初めて接続するサーバへアクセスすると、次のようなメッセージが表示されます。
The authenticity of host can't be established.
ED25519 key fingerprint is SHA256:xxxxxxxx
Are you sure you want to continue connecting (yes/no)?
これは接続先サーバのホスト鍵を確認している状態です。
「yes」を入力するとホスト鍵情報が保存されます。
保存先は以下です。
~/.ssh/known_hosts
StrictHostKeyCheckingの設定値
StrictHostKeyCheckingには主に3つの設定があります。
| 設定値 | 動作 |
|---|---|
| yes | 未登録サーバへの接続を拒否 |
| ask | 利用者へ確認を求める |
| no | 自動登録して接続 |
OpenSSHの多くの環境ではaskがデフォルトになっています。
StrictHostKeyChecking yes
最も厳格な設定です。
ssh -o StrictHostKeyChecking=yes user@server未登録サーバには接続できません。
known_hostsに登録済みであることが必須になります。
高いセキュリティを求める環境で利用されます。
StrictHostKeyChecking ask
一般的な設定です。
ssh -o StrictHostKeyChecking=ask user@server未登録サーバの場合は確認画面が表示されます。
利用者が判断して登録できます。
多くのLinux環境で標準設定となっています。
StrictHostKeyChecking no
自動的にホスト鍵を登録します。
$ ssh -o StrictHostKeyChecking=no user@server確認画面は表示されません。
自動化処理では便利ですが注意が必要です。
偽サーバへ接続しても警告されない可能性があります。
設定ファイルで指定する方法
毎回オプションを指定する代わりにSSH設定ファイルへ記述できます。
~/.ssh/config
例です。
Host server01
HostName 192.168.60.101
User student
StrictHostKeyChecking askサーバごとに設定できます。
known_hostsとの関係
StrictHostKeyCheckingはknown_hostsを利用して動作します。
接続時には以下を比較しています。
- known_hostsに保存されたホスト鍵
- サーバから送信されたホスト鍵
一致しない場合は警告が表示されます。
ホスト鍵変更時の動作
サーバ再構築などでホスト鍵が変わると以下の警告が表示されます。
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
これはknown_hostsの内容と異なるためです。
中間者攻撃の可能性もあるため、必ず原因を確認する必要があります。
自動化環境での利用
Ansibleやシェルスクリプトでは以下のような指定を見かけることがあります。
ssh -o StrictHostKeyChecking=no user@server初回接続時の確認画面を回避できるためです。
しかしセキュリティ面では推奨されません。
本番環境では慎重に利用する必要があります。
Ansibleではどうするのか
Ansibleでは事前にknown_hostsへ登録する方法が推奨されます。
例えばssh-keyscanを利用します。
$ ssh-keyscan server01 >> ~/.ssh/known_hostsこれにより安全に自動化できます。
ssh-keyscanとは
サーバのホスト鍵を取得するコマンドです。
$ ssh-keyscan 192.168.60.101
出力例です。
192.168.60.101 ssh-ed25519 AAAA...known_hostsの事前登録によく利用されます。
実務で推奨される運用
企業環境では以下の運用が一般的です。
- 初回接続時にフィンガープリント確認
- known_hostsへ登録
- StrictHostKeyCheckingを有効化
- サーバ再構築時は再確認
安易にnoを利用しないことが重要です。
学習環境ではどうするべきか
VirtualBoxや検証環境では頻繁にサーバを再構築するため、known_hostsの更新が多く発生します。
そのため一時的にStrictHostKeyChecking=noを利用するケースもあります。
ただし、本番環境では利用しない方が安全です。
よくあるトラブル
Host key verification failed
known_hostsの情報と一致しない場合に発生します。
古い情報を削除します。
$ ssh-keygen -R 192.168.60.101接続確認が毎回表示される
known_hostsへ保存できていない可能性があります。
権限やホームディレクトリを確認しましょう。
まとめ
StrictHostKeyCheckingはSSH接続時のホスト鍵検証を制御する重要な設定です。
SSHが中間者攻撃を防ぐための仕組みの一つであり、known_hostsと連携して接続先サーバの正当性を確認しています。
自動化環境では便利さからStrictHostKeyChecking=noが利用されることもありますが、セキュリティリスクを理解したうえで利用することが重要です。
本番環境ではホスト鍵を適切に管理し、安全なSSH運用を心掛けましょう。
