Странична SSH публични ключове добавя файл с разрешени клавиши на Linux VM

Проверете

За да проверите дали имате допълнителни ключове, прегледайте разрешение ключовете файл (vi .ssh/authorized_keys) да се определи дали са добавени всички допълнителни ключове, които не възнамерявате да включите.

Това е безопасно да ръчно премахване на допълнителни ssh публични ключове, които може да са добавени. Това не засяга функциите, които са внедрени с VM. Също така то няма да засегне на указаната двойка SSH ключове за удостоверяване.

Ако не знаете или не разграничение кои публични ключове в .ssh/authorized_keys файлът, който зададохте за удостоверяване, изпълнете следните стъпки:

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

   1. SSH публични ключове

   2. SSH ключове в облак първоначалната конфигурация

2. Възстановете разположено ssh ключове по време на създаване в VM, ако имате sudo/root достъп. За да направите това, изпълнете следните стъпки:

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

   2. Освен това, проверете например мета данни услуги (IMDS) за да видите ssh публичен ключ, който е приет в ssh публичен ключ собственост на VM създаване: 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 е разположена с разширения или управлявани самоличност. Това ще не премахнете ключовете, които са посочени, когато сте въвели 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. Получи име на ключ хранилище сертификат, който сте въвели чрез VM, прегледайте разполагане код я CLI или ARM шаблони или стартирате тази я 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 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 изображения с помощта на тези стъпки (или друг подобен метод), трябва да актуализирате изображението източник, от който сте създали виртуални машини. Допълнителни стъпки, които трябва да добавите към съществуващите източник 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

облак-първоначален пакети

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