Linux VM 上の承認キー ファイルに追加された無関係な SSH 公開キー

適用先
Virtual Machine running Linux

概要

Microsoft Azure プラットフォームでは、ユーザーが認証のために独自の SSH キー ペアを提供できるようにするだけでなく、SSH キー ペアを使用して、デプロイ時に仮想マシン (VM) に追加される一部の機能を有効にします。 いくつかの限定的なシナリオで、これらのAzure プラットフォーム証明書の公開キーが予期せず .ssh/authorized_keys ファイルに追加される可能性があることが最近判明しました。 これらのシナリオは、cloud-init を使用して VM がプロビジョニングされ、ユーザーがシステム管理サービス ID などの証明書に依存する追加の Azure 機能を選択する状況にのみ対象としています。

この予期しない動作は、特定のオペレーティング システムのプロビジョニング ロジックの変更が原因で発生します。 これらは、cloud-init を使用し、VM の作成中に VM で使用できる すべての 証明書の公開キーを ssh 承認キー ファイルに誤ってインストールするシステムです。  

詳細については、 CVE-2019-0816 を参照してください。

詳細情報

シナリオの詳細

「概要」セクションで説明されている cloud-init ロジックは、パブリック プレビューの RHEL 7.4/7.5/7.6 および CentOS 7.4 cloud-init イメージに加えて、Ubuntu 18.04 の Azure イメージに現在存在することがわかっています。 また、これらのオペレーティング システムを使用するカスタム イメージに存在する場合もあります。 
 
Linux イメージのいずれかをプロビジョニングするときに次のいずれかの機能を有効にすると、次のいずれかのような予期しないキーが .ssh/authorized_keys ファイルに表示される場合があります。

  • マネージド ID
  • 保護された設定を持つ拡張機能
  • VM 内の Key Vault キーを使用して VM をデプロイする

既存の VM を特定して修復する

値の

追加のキーがあるかどうかをチェックするには、承認されたキー ファイル (vi .ssh/authorized_keys ファイル) を参照して、含めるつもりがなかった追加のキーが追加されていないか判断します。

追加された可能性のある追加の ssh 公開キーは手動で削除しても安全です。 これは、VM と共に配置される機能には影響 しません 。 また、認証用に指定した SSH キーのペアには影響しません。

認証用に指定した .ssh/authorized_keys ファイル内の公開キーがわからない場合、または区別できない場合は、次の手順を実行します。

  1. 展開テンプレートを確認します。

    1. SSH 公開キー
    2. cloud-init 構成の SSH キー

  2. sudo/root アクセス権がある場合は、VM 内から作成時にデプロイされた ssh キーを取得します。 手順は次のとおりです。

    1. CustomData で渡された cloud-init 構成を確認します: sudo cat /var/lib/waagent/ovf-env.xml |grep "<ns1:CustomData>"
      CustomData 値を使用し、base64 デコードを使用して、デプロイした公開キーを取得します。

echo "<customData value>" | base64 -D 2.または、インスタンス メタデータ サービス (IMDS) チェック、VM の ssh 公開キー プロパティで渡された ssh 公開キーを確認します 作成: curl -H Metadata:true "http://169.254.169.254/metadata/instance/compute/publicKeys?api-version=2018-04-02&format=json"

リスク

VM にデプロイする必要のない追加の証明書を特定した場合は、authorized_keys ファイルから対応する行を消去することで、これらの証明書を削除できます。

VM に対話的に接続して修復を実行するか、複数の VM でカスタム スクリプト拡張機能または RunCommand を使用します。

保護された設定またはマネージド ID を持つ拡張機能を使用してデプロイされた VM

次のスクリプトを使用して、拡張機能またはマネージド ID を使用して VM がデプロイされた証明書から公開キーを削除します。 これによって、VM をデプロイしたとき、または VM が Key Vault キーを使用してデプロイされたときに指定されたキーは削除されません。

重要

このスクリプトを実行する前に、authorized_keys ファイルをバックアップすることをお勧めします。

 


#!/bin/bash
set -e

# /var/lib/waagent has *.crt files that include the crt files corresponding to 
# the user provided public keys and one additional .crt file from MSI.
# This script converts the content of the .crt file into the ssh public key and
# remove it from the authorized_keys file
readarray -t CRT_FILES < <(grep -l -E "(Microsoft.ManagedIdentity|Windows Azure)" /var/lib/waagent/*.crt)
for ((i=0; i < ${#CRT_FILES[@]}; i++))
do
    PUBKEY=$(openssl x509 -in "${CRT_FILES[$i]}" -pubkey -noout | ssh-keygen -f /dev/stdin -i -m PKCS8)
    sed -i -e "\@$PUBKEY@d" $HOME/.ssh/authorized_keys
Done

スクリプトが実行されたら、ssh/authorized_keys ファイルをチェックして、既知の公開キーのみが存在することを確認します。

Key Vault シークレットを使用してデプロイされた VM

Key Vault キーを使用してデプロイされたときにキーが追加されたかどうかを確認するには、次の手順を実行します。

  1. VM を使用してデプロイした Key Vault 証明書の名前を取得するか、デプロイ コードを確認する Az CLI または ARM テンプレート、または次の Az CLI を実行します。
     az vm show --resource-group <resourceGroupName> --name <vmName> | grep certificateUrl

    応答には、証明書名が表示されます。
     "certificateUrl": "https://<keyVaultname>.vault.azure.net/secrets/<certName>/xxxxxxxxxxxxx"

  2. 証明書をダウンロードします。
     az keyvault certificate download --vault-name <keyVaultName> --name <certName> --encoding PEM --file public.pem

  3. 公開キーを抽出します。
     openssl x509 -in public.pm -pubkey -noout |ssh-keygen -f /dev/stdin -i -m PKCS8

  4. 前の手順の出力を、ssh/authorized_keys ファイル内の残りの証明書と比較します。
     vi .ssh/authorized_keys ファイル

解決策

Azure MarketPlace イメージ

修正プログラムは、識別された Azure イメージの cloud-init に適用されました:

  • Canonical:UbuntuServer:18.04-LTS:18.04.201902190
  • Canonical:UbuntuServer:18.10-DAILY:18.10.201903200
  • RedHat:RHEL:7-RAW-CI:7.6.2019030421
  • OpenLogic:CentOS-CI:7-CI:7.6.20190306

カスタム イメージ

既知のオペレーティング システム用に cloud-init によってプロビジョニングされたカスタム イメージを使用している場合は、ソース カスタム イメージを更新する必要があります。

Ubuntu 18.04 イメージ

ソース カスタム イメージを更新するには、以下の変更を行う必要があります。

  • 次のファイルを編集します。

    /etc/cloud/cloud.cfg.d/90-azure.cfg

  • ファイルの末尾に次のコードを追加します。

重要

コードは、スペースも含めて、示されているとおりに正確に追加する必要があります。


datasource:
   Azure:
     agent_command: [service, walinuxagent, start]

RHEL 7.4/7.5/7.6 および CentOS 7.6 イメージ

これらの手順 (または同様の方法 ) を使用して 以前に RHEL/CentOS イメージを作成した場合は、VM の作成元のソース イメージを更新する必要があります。 既存のソース VM イメージ構成に追加するために必要な追加の手順を次に示します。

手順 1 

次のファイルを編集します。

/etc/cloud/cloud.cfg.d/91-azure_datasource.cfg

重要

コードは、スペースも含めて、示されているとおりに正確に追加する必要があります。

ファイルの末尾に次の行を追加します。 


datasource:
   Azure:
     agent_command: [systemctl, start, waagent, --no-block]

手順 2

エージェント構成を次のように更新します。


cp /lib/systemd/system/waagent.service /etc/systemd/system/waagent.service
sed -i 's/After=network-online.target/WantedBy=cloud-init.service\\nAfter=network.service systemd-networkd-wait-online.service/g' /etc/systemd/system/waagent.service
systemctl daemon-reload

cloud-init パッケージ

修正プログラムを含むすべての cloud-init パッケージは現在更新中です。 マイクロソフトでは、この問題について現在調査中です。詳細については、わかりしだいこの資料に掲載する予定です。 

よく寄せられる質問

Q1: Microsoft は私の VM へのアクセス権を取得しましたか?

A1: 暗号化キーは ID の管理に使用され、拡張機能は Microsoft の従業員によるアクセス用に設計されていません。 この種のアクセスを監視、記録、防止するためのプロセスが用意されています。 安全対策として、Microsoft ではすべてのログを確認し、顧客キーに不適切なアクセスがないことを確認しています。 VM または VMSS デプロイで参照される Key Vault に格納されている証明書の場合、Microsoft の従業員はシークレットにアクセスできません。

Q2: cloud-init で展開されたすべての OS とバージョンが影響を受けますか?

A2: いいえ。 この不要なキーの問題は、特定されたオペレーティング システムでのみ発生することがわかりました。 古いバージョンのUbuntuでは発生していません。 これは、これらのシステムが異なるメカニズムを使用して公開キーを設定するためです。

Q3: Linux ディストリビューションの影響を受ける cloud-init パッケージには修正プログラムが含まれていますか?

A3: 影響を受けるバージョンのパッケージに修正プログラムを追加する作業に取り組んでおり、その作業が完了したら、この記事を更新します。

Q4: 影響を受ける VM は自動的に更新されますか?

A4: いいえ。 Microsoft は、既にプロビジョニングした VM の内容を変更することはありません。

Q5: セキュリティ ポリシーにより、authorized_keys で無関係なコンテンツを含む Linux VM を操作することができません。 この問題に対して今日何ができますか?

A5: 問題のある行は、authorized_keys ファイルから安全に削除できます。 これは、作成して制御する SSH キー ペアやマネージド ID には影響しません。 これは手動で行うことも、影響を受けるフリート全体でカスタム スクリプトまたはカスタム コマンドを実行することで行うこともできます。