概要
EC2 Instance Connectは、SSH接続時に一時的な公開鍵をインスタンスに送信することで、長期的なSSHキーペアの管理を不要にする機能です。この機能にはホストキー検証の仕組みが組み込まれており、接続先のEC2インスタンスが正当なサーバーであることを確認します。
しかし、EC2インスタンスのSSHホストキーをローテーションした場合、AWSの信頼済みホストキーデータベースに新しいホストキーが登録されていないと、EC2 Instance Connect経由の接続でホストキー検証エラーが発生します。
本記事では、EC2 Instance Connectにおけるホストキー検証の仕組みを解説し、ホストキーローテーション後のエラーを解決する方法を紹介します。
この記事のメリット
- EC2 Instance Connectの接続の仕組みを理解できる
- SSHホストキーとSSHキーペア（ユーザー認証鍵）の違いを明確に区別できる
- ホストキー検証の仕組みと、検証エラーが発生する原因を理解できる
- ホストキーの再登録手順（
eic_harvest_hostkeysの実行、Amazon Linux 2023 では再起動）を習得できる - SCS試験で「EC2 Instance Connectのホストキー検証エラー」に関する問いに正確に答えられるようになる
執筆者とキャラクター紹介
執筆者：土肥（とひ）
株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。
クラウドおさる
クラウドおさるはじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。
クラウドおさる基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。
クラウドおさる猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。
技術解説
EC2 Instance Connectの接続フロー
EC2 Instance Connectの接続は、以下の流れで行われます。
- ユーザーがEC2 Instance Connect API（
ec2-instance-connect:SendSSHPublicKey）を呼び出し、一時的なSSH公開鍵をインスタンスのメタデータに送信する - 送信された公開鍵は60秒間だけ有効で、インスタンスメタデータサービス（IMDS）経由でインスタンスに提供される
- インスタンス上のSSHデーモンが
eic_run_authorized_keysコマンドを実行し、IMDSから一時的な公開鍵を取得してユーザー認証に使用する - 認証が成功するとSSHセッションが確立される
ブラウザベースのクライアント（EC2コンソール）を使用する場合は、AWS側でホストキー検証が行われます。この検証では、インスタンスのSSHホストキーがAWSの信頼済みホストキーデータベースに登録されているキーと一致するかが確認されます。
SSHホストキーとSSHキーペアの違い
SSHには「ホストキー」と「キーペア（ユーザー認証鍵）」という2種類の鍵があり、役割が異なります。
| 項目 | SSHホストキー | SSHキーペア（ユーザー認証鍵） |
|---|---|---|
| 目的 | サーバーの身元を証明する（中間者攻撃の防止） | ユーザーの身元を証明する（ユーザー認証） |
| 生成元 | インスタンスのSSHデーモン（OS起動時に自動生成） | ユーザー（ローカル）またはEC2起動時に生成 |
| 保存場所 | インスタンスの/etc/ssh/ssh_host_* | 秘密鍵: クライアント側、公開鍵: インスタンスの~/.ssh/authorized_keys |
| ライフサイクル | 長期（手動でローテーションするまで有効） | EC2キーペア: 長期、EC2 Instance Connectの一時鍵: 60秒 |
ホストキーは「このサーバーは前回接続したサーバーと同一である」ことをクライアントに保証するための仕組みです。ホストキーが変わると、クライアント側では「接続先のサーバーが別のサーバーに置き換わった可能性がある」と判断します。
ホストキー検証の仕組み
EC2 Instance Connectのブラウザベースクライアントは、以下の仕組みでホストキー検証を行います。
- インスタンス起動時: インスタンス上のSSHホストキー（
/etc/ssh/*.pub）がAWSの信頼済みホストキーデータベースに登録される - 接続時: ブラウザベースクライアントがSSH接続を開始すると、インスタンスから提示されたホストキーを信頼済みホストキーデータベースと照合する
- 一致すれば接続成功、不一致であればホストキー検証エラーとなる
登録の実体はAMIによって異なります。Amazon Linux 2 や Ubuntu では EC2 Instance Connect パッケージに含まれる eic_harvest_hostkeys スクリプトが起動時に実行されます。このスクリプトは、インスタンスのインスタンスアイデンティティ認証情報（/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance/）を使ってAWS APIを呼び出すため、IAMインスタンスプロファイルのアタッチは不要です。
ホストキーローテーション後にエラーが発生する理由
ホストキーの登録はインスタンスの起動時に行われます。そのため、起動後にホストキーを手動でローテーションした場合、以下の状態になります。
- インスタンス上のホストキー: 新しいキーに更新済み
- AWSの信頼済みホストキーデータベース: 古いキーのまま
この不一致により、EC2 Instance Connectのブラウザベースクライアントがホストキー検証に失敗し、接続エラーが発生します。
各選択肢の比較
ホストキー検証エラーの解決策として以下の方法が考えられますが、適切な方法は1つです。
| 対策 | 有効か | 理由 |
|---|---|---|
| 新しいホストキーをAWSの信頼済みホストキーデータベースにアップロードする | はい | eic_harvest_hostkeysの再実行（Amazon Linux 2023 では再起動）により、新しいホストキーがデータベースに登録され、検証エラーが解消される |
| ホストキーをSystems Managerパラメータストアに保存する | いいえ | パラメータストアはEC2 Instance Connectのホストキー検証プロセスとは無関係 |
| インスタンスプロファイルにAmazonSSMManagedInstanceCoreポリシーを付与する | いいえ | このポリシーはSystems Manager用であり、EC2 Instance Connectのホストキー検証には関係しない |
| 新しいSSHキーペアを作成する | いいえ | SSHキーペアはユーザー認証に使用されるもので、ホストキーの検証エラーは解決しない |
実践
ここでは、EC2インスタンスのSSHホストキーをローテーションしてEC2 Instance Connectの検証エラーを再現し、新しいホストキーをAWSの信頼済みホストキーデータベースに再登録して解消するまでを実施します。
前提条件
- リージョン:
ap-northeast-1（東京） - Amazon Linux 2023のEC2インスタンスが1台起動済みであること
- EC2 Instance Connectパッケージがインストール済みであること（Amazon Linux 2023ではデフォルトでインストール済み。ただし後述のとおり
eic_harvest_hostkeysは含まれません） - EC2 Instance Connectのブラウザベースクライアントで対象インスタンスに接続できる状態であること
Amazon Linux 2023（標準AMI）ではEC2 Instance Connectパッケージがプリインストールされているため、追加のインストール作業は不要です。Minimal AMIを使用している場合は手動でのインストールが必要です。
手順1: 現在のホストキーの確認
まず、EC2 Instance Connectのブラウザベースクライアントで対象のインスタンスに接続し、現在のホストキーを確認します。
- AWSマネジメントコンソールにログインし、右上のリージョンが「アジアパシフィック（東京） ap-northeast-1」であることを確認します
- 上部の検索バーに
EC2と入力し、表示された「EC2」を選択します - 左側ナビゲーションの「インスタンス」→「インスタンス」を選択します
- 対象のインスタンスを選択し、「接続」をクリックします
- 「Linux インスタンスに接続」画面が開きます。「ウェブブラウザで」タブで「接続方法を選択」から「パブリックサブネットアクセス（管理対象 SSH キー / EC2 Instance Connect）」を選びます
- 「ユーザー名」が
ec2-userであることを確認し、右下の「接続」をクリックします - ブラウザベースのターミナルが開いたら、以下のコマンドで現在のホストキーのフィンガープリントを確認します
sudo ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub
sudo ssh-keygen -l -f /etc/ssh/ssh_host_ecdsa_key.pub表示されたフィンガープリントを控えておきます。
手順2: ホストキーのローテーション
SSHホストキーを再生成します。
sudo rm /etc/ssh/ssh_host_*
sudo ssh-keygen -A新しいホストキーが生成されたことを確認します。
sudo ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub
sudo ssh-keygen -l -f /etc/ssh/ssh_host_ecdsa_key.pub手順1で確認したフィンガープリントとは異なる値が表示されます。
SSHデーモンを再起動して新しいホストキーを反映します。
sudo systemctl restart sshdSSHデーモンの再起動後、現在のセッションは維持されますが、新しいSSH接続では新しいホストキーが使用されます。
手順3: ホストキー検証エラーの確認
この時点でEC2 Instance Connectのブラウザベースクライアントから再度接続を試みると、ホストキー検証エラーが発生することを確認します。
- EC2コンソールのインスタンス一覧に戻り、対象のインスタンスを選択して「接続」をクリックします
- 同じ手順で「接続」をクリックします
- しばらく「Establishing Connection …」と表示されたあと、Host Key Verification の警告ダイアログが表示されます
WARNING: Your EC2 instance host key has changed. Either someone is eavesdropping on you (man-in-the-middle attack) or your system administrator changed the host key. … Are you sure you want to continue connecting? (yes/no)
これは、AWSの信頼済みホストキーデータベースに登録されているホストキーと、インスタンス上の新しいホストキーが一致しないために発生しています。ここで「Yes」を選んでも、その先で「Failed to connect to your instance」となり接続はできません。
手順4: 新しいホストキーをAWSの信頼済みホストキーデータベースに登録
新しいホストキーをAWS側に登録し直します。方法はAMIによって異なります。
Amazon Linux 2 / Ubuntu の場合: eic_harvest_hostkeys を実行する
EC2キーペアを使った通常のSSH接続などでインスタンスにログインし、eic_harvest_hostkeysスクリプトを実行します。
# Amazon Linux 2
sudo /opt/aws/bin/eic_harvest_hostkeys
# Ubuntu
sudo /usr/share/ec2-instance-connect/eic_harvest_hostkeysスクリプトが正常に完了すると、特に出力は表示されません。エラーメッセージが表示されなければ成功です。
Amazon Linux 2023 の場合: インスタンスを再起動する
Amazon Linux 2023 の ec2-instance-connect パッケージ（検証時のバージョンは 1.1-19.amzn2023）には eic_harvest_hostkeys が含まれていません。パッケージが提供するのは以下の3つだけです。
$ rpm -ql ec2-instance-connect
/opt/aws/bin/eic_curl_authorized_keys
/opt/aws/bin/eic_parse_authorized_keys
/opt/aws/bin/eic_run_authorized_keysそのため sudo /opt/aws/bin/eic_harvest_hostkeys を実行しても command not found になります。この場合はインスタンスを再起動します。起動時に新しいホストキーがAWS側へ登録され直し、ブラウザベースクライアントから接続できるようになります。
- EC2コンソールのインスタンス一覧で対象のインスタンスを選択します
- 「インスタンスの状態」→「インスタンスを再起動」をクリックします
- ステータスチェックが通るまで待ちます
手順5: 接続の再確認
EC2 Instance Connectのブラウザベースクライアントで再度接続を試みます。
- EC2コンソールのインスタンス一覧に戻り、対象のインスタンスを選択して「接続」をクリックします
- 同じ手順で「接続」をクリックします
- Host Key Verification の警告が出なくなり、正常にブラウザベースのターミナルが表示されることを確認します
- 手順2で再生成したフィンガープリントのままであることも確認できます
まとめ
EC2 Instance Connectのブラウザベースクライアントは、SSHホストキーをAWSの信頼済みホストキーデータベースと照合して接続先インスタンスの正当性を検証します。
| 状況 | 対処方法 |
|---|---|
| ホストキーローテーション後にEC2 Instance Connectで検証エラーが発生する（Amazon Linux 2 / Ubuntu） | eic_harvest_hostkeysスクリプトを実行し、新しいホストキーを信頼済みホストキーデータベースに登録する |
| 同上（Amazon Linux 2023） | パッケージに eic_harvest_hostkeys が含まれないため、インスタンスを再起動して新しいホストキーを登録し直す |
| Systems Managerパラメータストアにホストキーを保存する | EC2 Instance Connectのホストキー検証プロセスとは無関係のため、エラーは解消しない |
| AmazonSSMManagedInstanceCoreポリシーを付与する | Systems Manager用のポリシーであり、ホストキー検証には影響しない |
| 新しいSSHキーペアを作成する | ユーザー認証鍵の変更であり、ホストキー（サーバー認証鍵）の問題は解決しない |
ホストキーとSSHキーペア（ユーザー認証鍵）は役割が異なります。ホストキーはサーバーの身元を証明する鍵であり、SSHキーペアはユーザーの身元を証明する鍵です。ホストキー検証エラーの解決には、ホストキー自体の再登録が必要であり、ユーザー認証鍵の変更では解決できません。
eic_harvest_hostkeysスクリプトはインスタンス起動時にsystemdによって自動実行されますが、起動後にホストキーを手動ローテーションした場合は再度手動で実行する必要があります。
参照先
- EC2 Instance Connect を使用した Linux インスタンスへの接続 – Amazon EC2
- EC2 インスタンスに EC2 Instance Connect をインストール – Amazon EC2
- Amazon EC2 Linux インスタンスへの接続に関する問題のトラブルシューティング – Amazon EC2
- AL2023 インスタンスへの接続 – Amazon Linux 2023
