「Authenticity of Host Can’t Be Established（ホストの信頼性が確立できません）」エラーは、通常SSH（セキュアシェル）でサーバーに接続する際に発生します。このエラーは、第三者がサーバーIDを悪用しているなど、深刻な問題を示唆している可能性があります。

幸い、このエラーを解決して、安全かつスムーズな接続を確保する方法は複数あります。例えば、自己認証局（CA）を作成したり、SSHソフトウェアを更新したり、リモートホストの確認したりなど。

今回は、この「Authenticity of Host Can’t Be Established」エラーについて掘り下げ、発生原因と8つの解決策をご紹介していきます。

「Authenticity of Host Can’t Be Established」エラーとは

「Authenticity of Host Can’t Be Established」エラーは、SSH（セキュアシェル）使用時に発生する一般的なエラーです。SSH接続には、通常パスワードによる認証が必要になります。

また、公開鍵を使って認証を行うことも可能で、その場合には公開鍵と秘密鍵からなるSSHキーペアを生成します。秘密鍵は自分のシステム上に残り、公開鍵は接続先のシステムにコピーされます。

ほとんどの場合、このエラーはSSHでサーバーに初めて接続する際に発生します。これは、SSHクライアントがそのサーバーをまだ理解していないためです。

信頼できるサーバーであることがわかっていれば、そのままエラーを解除して問題ありません。これによって、SSH鍵がknown_hostsファイルに格納され、次回以降の接続時には、ホストから取得した鍵とknown_hostsファイル内の鍵を照らし合わせ、サーバーの身元が確認されます。

以前に接続したことのあるサーバーに接続し、このエラーが発生した場合は、通常サーバーが別の鍵で再設定されたことを示唆していますが、深刻な問題が生じている可能性もあるため注意が必要です。

例えば、何者かがサーバーの身元を偽り、接続を介して送信されるデータを傍受しようとしているかもしれません。次のセクションで、このエラーが発生する主な原因について詳しく見ていきます。

「Authenticity of Host Can’t Be Established」エラーの原因

「Authenticity of Host Can’t Be Established」エラーの原因はさまざま。以下、特に一般的なものをご紹介します。

  • リモートホストの公開鍵が変更された：これは通常、サーバーが更新されたことを意味しますが、悪意あるユーザーがなりすましを行い、ホストが侵害されている可能性もあります。
  • 初めてリモートホストに接続する：SSHがサーバーを認識していないことが原因で、エラーを返すことがあります。
  • 複数のホスト公開鍵がある：サーバーは、ECDSAやRSAなどの複数の公開鍵暗号を持つことができます。異なる公開鍵を使用していると、エラーが発生することがあります。
  • ホストの公開鍵が削除されたまたは破損している：SSHExceptionが発生し、このエラーが表示されることがあります。
  • リモートホストのDNS設定に誤りがある：ドメインネームシステム（DNS）の設定に誤りがある場合は、不正な公開鍵を持つホストに接続される可能性があります。
  • 中間者（MITM）攻撃：攻撃者が自分（ローカルホスト）とリモートホスト間の接続を傍受していることを示唆していることも考えられます。

より良いセキュリティとパフォーマンスには、質の高いホスティングサービスを利用することが重要です。Kinstaのアプリケーションホスティングでは、Google Cloud Platformsのインフラストラクチャ上でプロジェクトを実行することができます。

Kinstaのアプリケーションホスティング
Kinstaのアプリケーションホスティング

また、Kinstaのプラットフォームは、Cloudflareのエンタープライズレベルのセキュリティ機能を搭載。ファイアウォールやDDoS対策などが含まれます。

さらに、SSL証明書も無料で使用でき、必要に応じて独自SSEL証明書のインストールも可能です。使用した分だけ支払うシンプルな価格設定で、ビジネスの成長に合わせてリソースを簡単に拡張可能です。

「Authenticity of Host Can’t Be Established」エラーを解決するには（8つの方法）

「Authenticity of Host Can’t Be Established」エラーの概要を押さえたところで、早速その解決策を見ていきましょう。

1. 接続を確認する

まず最初のトラブルシューティングは、ネットワーク接続の安定性を確認すること。また、接続をブロックしているものがないかも調査してみてください。

例えば、ウイルス対策ソフトやウェブアプリケーションファイアウォール（WAF）を利用している場合は、接続の妨げになる可能性があります。そのため、一時的にソフトウェアを無効にして、エラーが消えるかどうかを確認します。

2. IPアドレスを置き換える

一般的に、リモートホストは1つの公開鍵しか持っていないと思われがちですが、これは間違いで、複数の公開鍵を持つことができます。つまり、RSA鍵を使用していても、サーバーがECDSA鍵を提示している可能性があります。

このように公開鍵が異なる場合も、エラーの発生原因に。HostKeyAlgorithmsを設定した場合には、SSHで指定された設定が優先されるようになります。

~/.ssh/configファイルと/etc/ssh/ssh_configファイルで、この設定が行われているかどうかを確認します。設定されている場合は、~/.ssh/configファイルに以下を貼り付けてください。

# Update with the real IP address. Host 192.0.2.1 HostKeyAlgorithms rsa-sha2-512,rsa-sha2-256,ssh-rsa

これによって、SHA-1署名の使用が可能になります。ただし、SHA-1署名は脆弱性が度々検出されているため、安全とは言えません。そのため、サーバーがSHA-2署名をサポートしている場合には、このコマンドを削除してください。

また、システムがハッシュ化されたエントリを使用しない場合もあり、追加した鍵が正しく設定されていないことも考えられます。

この場合は、同じ設定ファイルでHashKnownHostsを確認し、それに応じて調整を行ってください。また、「ssh-keygen -F 192.0.2.1 -l」でIPアドレスを置き換えて、一致するものがあるかどうかを確認することもできます。

3. ホスト鍵の確認を回避する

このエラーは無害である可能性もあります。例えば、最近サーバーの更新や再設定が行われ、それに応じてホスト公開鍵が単に変更されている場合は、特に問題はありません。

この場合、nullのknown_hostsファイルに鍵を送ることで、認証のステップを省略することができます。ファイルに以下のコードを貼り付けましょう。

$ ssh -o "UserKnownHostsFile=/dev/null" -o "StrictHostKeyChecking=no" user@host

また、~/.ssh/configで特定のユーザーに対して恒久的に設定することも可能です（ユーザーに対して設定する場合は、/etc/ssh/ssh_config）。

4. 自己認証局（CA）を作成する

ウェブブラウザには、X509証明書がデフォルトでインストールされているため、初めて訪問するサイトのSSL（セキュアソケッツレイヤー）証明書を信頼することができますが、SSHクライアントの中には、X509やPKIをサポートしていないものも。その場合、ベリサインのSSL証明書で認証のステップを回避することはできません。

ただし、自己認証局（CA）を作成してエラーを解決できる可能性があります。自己認証局によって、サーバーにログインすることができ、公開鍵を持つクライアントは、自動的にそのサーバーを信頼することになります。

まずは、SSHキーペアを生成します。以下のコマンドを実行してください。

ssh-keygen -f cert_signer

各サーバーのホスト公開鍵に以下の署名を行います。

ssh-keygen -s cert_signer -I cert_signer -h -n www.example.com -V +52w /etc/ssh/ssh_host_rsa_key.pub

これで、署名付きのホスト公開鍵が生成されます。

/etc/ssh/ssh_host_rsa_key-cert.pub

次に、/etc/ssh/sshd_configファイルに移動し、HostCertificateをHostCertificate /etc/ssh/ssh_host_rsa_key-cert.pubファイルに紐付けます。

SSHクライアントを再起動し、known_hostsファイルに以下のコードを貼り付けます。

@cert-authority *.example.com ssh-rsa AAAAB3Nz...cYwy+1Y2u/

上記コードには、以下が含まれます。

  • 認証局
  • ドメイン（example.com）
  • 公開鍵の内容

cert_signerの公開鍵は、cert_signerの秘密鍵によって署名されたホスト公開鍵を持つサーバーを信頼するため、これでエラーが解消されるはずです。

5. SSHクライアントを更新する

SSHクライアントソフトウェアを更新し、最新の状態にすることも解決策になり得ます。これによって、リモートホストとの互換性の問題を解決することができます。

更新には、接続の安定性や安全性を向上させるバグ修正やセキュリティパッチが含まれることが多いため、更新後、エラーが解消される可能性があります。

6. リモートホストを確認する

ホスト鍵が正しくない、または有効期限が切れている場合も、このエラーが発生する可能性があります。したがって、リモートホストの鍵が適切に生成され、有効であるかどうかを確認しましょう。

加えて、リモートサーバーがオンラインで接続可能な状態であること、そして対象のサーバーを装った悪意のあるサーバーではなく、正しいサーバーに接続しているかも確認しましょう。

まずは、「ssh-keyscan」コマンドでリモートホストを確認します。

ssh-keyscan example.com

このコマンドで、リモートホストの公開鍵が取得され、端末に表示されます。known_hostsファイルに保存されている鍵（またはサーバー管理者から提供された鍵）と照らし合わせましょう。

一致する場合、リモートホストは正しいサーバーである可能性が高いです。一致しない場合は、サーバー管理者に問題を報告し、接続を停止するのが最善の策です。

7. 古いホスト鍵を削除する

このエラーは、ホスト鍵が変更されたことを意味することもあるため、known_hostsファイルから古い鍵を削除して解決する可能性もあります。

リモートホストの鍵は、サーバー設定の変更やセキュリティ侵害によって更新されているかもしれません。この場合は、古いホスト鍵が新しいものと一致せずに、エラーを引き起こします。

known_hostsに格納されているリモートホストの公開鍵を削除するには、以下のコマンドを使用します。

ssh-keygen -R example.com

これで、known_hostsファイルから鍵が削除されます。次にSSHでサーバーに接続する際には、新たなホスト鍵の認証が必要になります。

8. DNSキャッシュをクリアする

サーバーのDNS（ドメインネームシステム）設定が誤っていることも考えられます。これによって誤った鍵で接続され、エラーにつながっているかもしれません。

これを解決する最も簡単な方法は、DNSキャッシュをクリアすること。検索バーに「cmd」と入力して、Windowsのコマンドプロンプトを開きましょう。

Windowsのコマンドプロンプト
Windowsのコマンドプロンプト

次に、以下のSSHコマンドを貼り付けます。

ipconfig/flushdns

これでエラーが解消され、問題なくサーバーに接続できるようになるはずです。

まとめ

「Authenticity of Host Can’t Be Established」エラーは、通常SSHでサーバーに接続しようとしたときに発生します。これは、サーバーで再設定が行われたことを示している可能性がある一方で、重要な問題を示唆していることもあります。

初回接続時にこのエラーメッセージが表示されるのは正常です。無視しても問題ありません。そうでない場合は、ホストを確認し、正しいサーバーに接続しているかどうかを確認しましょう。状況によっては、known_hostsファイルから古いホスト鍵を削除したり、SSHソフトウェアの更新が必要になったりするかもしれません。

アプリケーションのセキュリティを高める簡単な方法は、Kinstaのような優れたホスティングサービスを利用すること。Kinstaのすべてのプランには、あらゆる問題のトラブルシューティングを支援する、トップクラスのサポートをご用意しています。