☰

リモート GitHub サーバーの SSH フィンガープリントの変更を確認するにはどうすればよいですか?

tag-icon • tag-icon ssh git
リモート GitHub サーバーの SSH フィンガープリントの変更を確認するにはどうすればよいですか?

仕事用の github サーバーからプロジェクトをクローンしようとすると、このエラーが表示されます。今日の早い時間には問題なかったのですが、今日の午後に突然発生し始めました。

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:<fingerprint>.
Please contact your system administrator.
Add correct host key in /Users/<myname>/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /Users/<myname>/.ssh/known_hosts:1
ECDSA host key for github.companysite.com has changed and you have requested strict checking.

新しいキー ペアを生成しようとしましたが、解決しませんでした。問題は、github インスタンスのサーバーが変更されたかどうか、これが正当な新しいフィンガープリントなのか、それとも攻撃なのかを知る方法がないことです。会社の github の Web バージョンにはアクセスできます。信頼できるホスト ファイルにコピーする前に、Web ページからサーバーのフィンガープリントを確認し、受信しているフィンガープリントと比較する方法はありますか?

説明のために編集: これはパブリック github ではなく、私の会社のプライベート github インスタンスです。

答え1

新しいキーペアを生成しようとしましたが、解決しませんでした。

メッセージはあなたの鍵ペアについて話しているのではなく、サーバーの鍵ペアの変更です。（サーバーの鍵ペアの変更は文字通り原因メッセージが表示されない場合は、解決できない可能性があります。

信頼できるホスト ファイルにコピーする前に、Web ページを通じてサーバーのフィンガープリントを確認し、受信しているフィンガープリントと比較する方法はありますか?

GitHub Enterpriseにそのようなウェブページがあることを示す文書は見つかりませんでした。しかし、公式ドキュメントそれがしなかった2016 年 (2.3.x～2.7.x) には、次の文に従ってこのような Web ページがありました。

「GitHub Enterprise アプライアンスの SSH ホスト キー フィンガープリントを、すべてのエンドユーザーがアクセスできる場所に公開することを強くお勧めします。」これは、このような Web ページを作成するのは完全にシステム管理者の責任であることを意味します。

GitHub.com にはまだ統合された SSH フィンガープリント リストがないため (「ヘルプ」セクションに手動で更新された記事のみ)、GitHub Enterprise もその点が改善されているとは期待できません。

したがって、システム管理者がそのような Web ページを作成しておらず、ホストキーの変更も発表していない場合は、残された選択肢はあまりありません。

  • いくつかの異なるパスを試してフィンガープリントを比較することで、ネットワークベースの MITM 攻撃を排除することができます (1 つのパスにのみ MITM が存在する場合)。たとえば、サーバーがグローバルにアクセス可能であると仮定すると、最初に直接接続し、次に商用 VPN プロバイダー経由で接続し、次に会社の内部 VPN (存在する場合) 経由で接続して、結果を比較します。すべてが同一であれば、おそらく正当なフィンガープリントです。

  • 変更を無視して、とにかく接続することができます。会社の独自の LAN 内で接続している場合、MITM 攻撃の可能性はそれほど高くありません。(Web サイトに接続するとき、有効な TLS 証明書がありますか? それとも、SSH ホストキーが変更されると同時に有効でなくなったのですか? それとも、そもそも有効な証明書がなかったのですか? これは、MITM 攻撃とシステム管理者の無能さの指標として役立ちます。)

  • Please contact your system administrator.

関連情報