Azure Blob Storage での SSH ファイル転送プロトコル (SFTP) サポート用のホスト キー

この記事には、SFTP クライアントから Azure Blob Storage に接続するために使用される有効なホスト キーの一覧が記載されています。

BLOB ストレージでは、SSH ファイル転送プロトコル (SFTP) がサポートされるようになりました。 このサポートにより、SFTP エンドポイント経由で Blob Storage に安全に接続する機能が提供され、ファイル アクセス、ファイル転送、ファイル管理のために SFTP を利用できます。 詳細については、Azure Blob Storage での SSH ファイル転送 (SFTP) プロトコルのサポートに関するページを参照してください。

SFTP クライアントを使用して Blob Storage に接続するときには、ホスト キーを信頼するよう求められる場合があります。 この記事に記載されている一覧でそのキーを見つけることで、ホスト キーを検証できます。

よく寄せられる質問

SSH ホスト キーとは

SSH ホスト キーは、SSH サーバーと SFTP サーバーに属する公開キーと秘密キーのペアです。 これらは、接続時にサーバーの ID を確認するためにクライアントによって使用されます。 秘密キーはサーバー側に格納され、公開キーは接続操作中にクライアントに提示されます。 ほとんどのクライアントは、キーを確認して受け入れるオプションをユーザーに提示します。これにより、接続を続行できます。

詳細については、 SSH ホスト キー管理の説明を参照してください。

SSH ホスト キーは、ログインに使用される SSH キーとは異なりますか?

はい。 SSH ホスト キーは、サーバーに属する個別の秘密キーと公開キーのペアです。 ログインに使用される秘密キーと公開キーのペアは完全に分離され、ユーザーによって管理されます。 ホスト キーのローテーションは、ユーザーの SSH キーには影響しません。

クライアントはホスト キーを使用して何を行う必要がありますか?

クライアントの信頼されたホストの一覧に新しいホスト キーを追加することをお勧めします。 このアクションの手順は、使用される SFTP クライアントによって異なります。 クライアントが信頼されたホストを格納する最も一般的な方法は次のとおりです。

• known_hosts ファイル
• Windows レジストリ キー (Windows 固有のクライアント)
• 変数 (ライブラリ ベースのクライアント)

known_hosts の例

このファイルは、多くの場合、次のローカル パスの下に格納されます: ~/.ssh/known_hosts。 ファイルには既知のホストごとに 1 行が含まれており、各行は次のような形式に従う場合があります: <server hostname> <algorithm> <host key>。

最初に接続した時点から、ストレージ アカウントのエントリが既にある可能性があります。 同じリージョンとアルゴリズムの新しいキーを使用して、新しいエントリをその下に追加できます。 追加すると、 Australia Central と ecdsa-sha2-nistp256の次の例のようになります。

<account>.blob.core.windows.net ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBElXRuNJbnDPWZF84vNtTjt4I/842dWBPvPi2fkgOV//2e/Y9gh0koVVAYp6MotNodg4L9MS7IfV9nnFSKaJW3o=

<account>.blob.core.windows.net ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBLs9yqrEGdGvgdSWkAK5YkyazMWi30X+E6J/CiGpJwbuczVJwT/cwh+mxnE7DMTwhEo57jL7/wi/WT8CPfPpD4I=

最初のエントリは、サービスによって現在使用されているキーを対象としており、有効期限が早くなります。 2 番目のエントリは、回転後に使用される次のキー用です。 両方のエントリを使用すると、回転が発生したときにスムーズに切り替えられます。

レジストリ キーの例

WinSCP などの Windows ベースのクライアントの場合、信頼されたホストはレジストリ キー (HKEY_CURRENT_USER\Software\Martin Prikryl\WinSCP 2\SshHostKeys) に格納されます。

新しいホスト キーが表示されると、WinSCP によってキーを受け入れるように求められます。 SHA256 フィンガープリントを次の表の関連キーと比較し、一致する場合は受け入れます。 その後、WinSCP は新しいキーを将来のキャッシュに追加します。

ライブラリ クライアントの例

SSH.NETなどのライブラリ ベースのクライアントの場合、ホスト キーの検証は次のコード スニペットのようになります。

string expectedFingerPrint = "m2HCt3ESvMLlVBMwuo9jsQd9hJzPc/fe0WOJcoqO3RA=";

using (var client = new SshClient("<account>.blob.core.windows.net", "<account>.<user>", "<pwd>"))
{
    client.HostKeyReceived += (sender, e) =>
        {
            e.CanTrust = expectedFingerPrint.Equals(e.FingerPrintSHA256);
        };
    client.Connect();
}

次のホスト キーを考慮するために、次の変更を行うことができます。

List<string> expectedFingerPrints = new List<string>() { "m2HCt3ESvMLlVBMwuo9jsQd9hJzPc/fe0WOJcoqO3RA=", "5Vot7f2reXMzE6IR9GKiDCOz/bNf3lA0qYnBQzRgObo=" };

using (var client = new SshClient("<account>.blob.core.windows.net", "<account>.<user>", "<pwd>"))
{
    client.HostKeyReceived += (sender, e) =>
        {
            e.CanTrust = expectedFingerPrints.Contains(e.FingerPrintSHA256);
        };
    client.Connect();
}

クライアントは、古いホスト キーの有効期限が切れたときに新しいホスト キーを受け入れることはできますか?

はい。ただし、これはシームレスな移行にはなりません。 新しいキーが最初に表示されると、クライアントは次の種類のメッセージを返し、切断することがあります。

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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:Q3zIFfOI1UfCrMq6Eh7nP1/VIvgPn3QluTBkyZ2lfCw.
Please contact your system administrator.
Add correct host key in C:\\Users\\<user>/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in C:\\Users\\<user>/.ssh/known_hosts:8
Host key for <account>.blob.core.windows.net has changed and you have requested strict checking.
Host key verification failed.
Connection closed

これは、クライアントが known_hostsに古いキーのみを持っているために発生します。これは、サーバーによって提示されるキーとは異なります。 切断は、安全対策として行われます。 もう一度接続するには、クライアントは古いエントリを known_hosts から削除してから、もう一度接続する必要があります。 これにより、クライアントはホスト キーを確認して受け入れる機会が与えられます。

The authenticity of host 'blob.cbn06prdstr01a.store.core.windows.net' can't be established.
ECDSA key fingerprint is SHA256:Q3zIFfOI1UfCrMq6Eh7nP1/VIvgPn3QluTBkyZ2lfCw.
This host key is known by the following other names/addresses:
    C:\Users\<user>/.ssh/known_hosts:12: blob.cbn06prdstr01a.store.core.windows.net
Are you sure you want to continue connecting (yes/no/[fingerprint])?

検証には、クライアント出力からのフィンガープリントと、次の表に格納されているフィンガープリントの比較が含まれます。 一致する場合は、「続行する yes 」と入力すると、クライアントは新しいキーを将来の known_hosts に自動的に格納します。

キーローテーションのタイムラインは?

ホストキーの期限切れになると、Azure Storageはすべてのストレージアカウント間でホストキーをローテーションするプロセスを開始します。 異なるストレージアカウントは鍵のローテーションを異なるタイミングで経験します。 すべてのストレージアカウントは数ヶ月以内にホストキーが入れ替わるはずです。

回転にはどのくらいの時間がかかりますか?

ローテーションは段階的で、数週間かかることもあります。 ストレージアカウントのホストキーのローテーションが始まると、この期間中にAzureサービスによって古いまたは新しいホストキーのいずれかが表示されることがあります。 ローテーション中、クライアントは新しいホストキーが最初に表示された後でも、古いホストキーが表示されるのを見ることができました。

これは硬い期限ですか?

No. 有効期限はAzure Storageがホストキーのローテーションを開始する日を示します。 この日までにクライアントを更新しなければ、すぐに新しいホストキーが表示される可能性もありますが、すべてのホストキーがローテーションされるまで前のホストキーが残る可能性もあります。

ホスト キーの有効期限が切れるのはなぜですか?

シークレットを定期的にローテーションすることは標準的なセキュリティプラクティスであり、攻撃ベクトルを減らすのに役立ちます。

厳密なホスト キー検証を無効にしても問題ありませんか?

いいえ。厳密なホスト キーの検証を無効にすることはお勧めしません。 ここで公開されているホスト キーに対する接続中に提示されたホスト キーを確認すると、クライアントは Man-In-The-Middle (MITM) 攻撃の可能性から自分自身を保護できます。

有効なホスト キー

¹ SHA 256 フィンガープリントは、Open SSH と WinSCP によって使用されます。

関連項目

• Azure Blob Storage での SSH ファイル転送プロトコル (SFTP) サポート
• SSH ファイル転送プロトコル (SFTP) を使用して Azure Blob Storage に接続する
• Azure Blob Storage での SSH ファイル転送プロトコル (SFTP) のサポートに関する制限事項と既知の問題
• Azure BloB ストレージでの SSH ファイル転送プロトコル (SFTP) のパフォーマンスに関する考慮事項