Сторонні SSH відкритих ключів, додані до файлу уповноважений, розділи Linux VM

Визначення

Щоб перевірити, чи є додаткові розділи, перегляньте файл уповноважений розділи (vi .ssh/authorized_keys-файл), щоб визначити, чи будь-які додаткові розділи, ви не маєте намір включити було додано.

Це можна вручну видалити ssh спільного розділи, додаткові можна було додано. Це не впливає на функції, які розміщуються разом з VM. Крім того, не вплине до вказаного SSH пари для автентифікації.

Не знаєте, або не можуть розрізняти, яких відкритих ключів в .ssh/authorized_keys вказаний файл для перевірки автентичності, виконайте наведені нижче дії:

1. Перегляньте шаблони для розгортання:

   1. SSH відкритих ключів

   2. SSH розділи у хмарі ініціалізації та конфігурації

2. Отримання до розгорнутого ssh клавіші під час створення з всередині VM, якщо у вас є доступ до суду/кореневої. Щоб це зробити, виконайте такі дії:

   1. Перевірте передано CustomData конфігурації ініціалізації на хмари. sudo cat /var/lib/waagent/ovf-env.xml | grep "<ns1:CustomData>"За допомогою CustomData значення та натисніть base64 для використання декодувати отримати спільних розділи, які буде розгорнуто. echo "<customData value>" | base64 -D

   2. Також можна перевірити, екземпляр Meta даних служби (IMDS), щоб переглянути в ssh відкритий ключ, яке було вказано на ssh спільні властивості розділу віртуальної машини, створіть: curl -H Metadata:true "http://169.254.169.254/metadata/instance/compute/publicKeys?api-version=2018-04-02&format=json"

Видалення

Якщо ви визначили додаткові сертифікати, які не потрібно розгорнути до віртуальної машини, можна видалити ці шляхом видалення відповідний рядок з файлу authorized_keys.

Запускати з виправленням, підключення до віртуальної машини в інтерактивному режимі або за допомогою сценарію розширення користувача "або" в дії на кількох-віртуальних машин.

Віртуальні машини, що розгорнути за допомогою розширення, що мають параметри або на керовані посвідчення

Видалити відкритих ключів з сертифікатів, коли в VM розгортання з розширенням або керовані посвідчення за допомогою таких сценаріїв. Воно не видаляти ключі, які вказано під час час розгортання VM або з VM розгортання ключ сховища ключів.

#!/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 файл, щоб переконатися, що є лише зареєстрованих спільних задати.

Віртуальні машини, розгортання з ключем сховища таємниць

Щоб визначити, чи додано розділ під час розгортання ключа сховища ключів, виконайте такі дії:

1. Знайти ім'я розділу сховище сертифікатів, час розгортання за допомогою на Віртуальну переглянути код для розгортання Арізона CLI або ARM шаблони або запустити цей Арізона, командного РЯДКА: 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 file

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 зображення за допомогою цих дій (або подібний спосіб), необхідно оновити джерело зображення, з якого було створено у-віртуальних машин. Нижче наведено додаткові дії, необхідні для додавання до існуючого джерела конфігурації віртуальної машини зображення.

Крок 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

Хмарні ініціалізації та пакети.

Усі пакети ініціалізації на хмари, які містять виправлення, які зараз оновлюються. Корпорація Майкрософт має досліджувати проблему й доповнюватиме цієї статті в міру.