Pull to refresh
Veeam Software
Продукты для резервного копирования информации

Применение Veeam Backup для виртуальных машин под управлением Linux: аутентификация на основе сертификата

Reading time 5 min
Views 8.5K
С выходом Veeam Backup & Replication v8 пользователи принялись тщательно изучать новые функциональные возможности продукта. А поскольку «на вкус и цвет товарища нет», то каждый находит какие-то милые сердцу фичи лично для себя, причем это могут быть совсем скромные, «но оч-чень полезные подарки», то есть новые опции, которые сразу не бросаются в глаза, но над которыми кропотливо трудились разработчики. Так подобралась «великолепная восьмерка», может быть, не слишком нашумевших, но весьма полезных фич Veeam Backup & Replication v8. Мой сегодняшний рассказ про аутентификацию с использованием сертификата при доступе к гостевой ОС виртуальных машин под управлением Linux.
image

Для чего нам нужен доступ к гостевой ОС на Linux ВМ


Индексация гостевой файловой системы требуется для того, чтобы обеспечить пользователю удобный поиск и быстрое восстановление нужных файлов. В частности, Veeam Backup & Replication 8.0 поддерживает эту функциональность и для виртуальных машин под управлением Linux, предоставляя удобный веб-интерфейс Veeam Backup Enterprise Manager:
image
Соответствующие операции Veeam выполняет с помощью runtime-компонента, который запускается на гостевой ОС виртуальной машины с началом выполнения задания резервного копирования. Этот компонент координирует процессы при индексации (о них чуть позже), а по завершении задания прекращает работу. Для работы runtime-компонента на гостевой ОС и требуется аутентификация, для которой Veeam Backup & Replication 8 поддерживает теперь также использование сертификата (Linux public key).

Подробнее о индексации гостевой файловой системы см.здесь и здесь (на англ.яз.).

Почему мы решили поддержать Linux Public Key-аутентификацию


Те, кто работал с Linux-инфраструктурами, наверняка в курсе – редко кто логинится на Linux сервера, вводя имя пользователя и пароль. Причин тому несколько, среди них, в частности – отсутствие централизованного управления учетными записями. Да, кто-то использует Microsoft Active Directory через Kerberos, кто-то иные способы, но это отнюдь не массовое явление, и настройка и управление большим количеством учеток в немаленькой инфраструктуре может стать головной болью для того, кто за это отвечает.

Взять хотя бы пароли: все знают, что в целях безопасности следует использовать пароли достаточной сложности и регулярно их менять. Да на это же можно полжизни потратить! Кое-кто решает упростить задачу и использовать, скажем, никогда не меняющиеся пароли, или простые короткие пароли. Понятно, что жить становится легче, но безопасность при этом снижается. Помним еще, что кроме коммуникации «человек-компьютер» есть еще коммуникация «компьютер-компьютер», и чтобы обеспечить коммуникацию между серверами, следует хранить пароли там, где к ним был бы доступ у приложений и скриптов – при этом очень желательно в каком-то защищенном виде, а не в текстовом формате.

Из-за всего этого администраторы Linux-систем часто используют метод аутентификации с использованием сертификата, полностью отключая возможность логиниться с вводом имени и пароля. Идея состоит в том, чтобы пользователь (или сервер) использовал для доступа через SSH к удаленной машине сертификат, зарегистрированный на этой удаленной машине – что и позволяет получить авторизацию без необходимости ввода имени\пароля.

Этот сертификат нужно зарегистрировать всего один раз, после чего доступ будет предоставляться автоматически. Выдачу сертификатов также можно автоматизировать.

Если на Linux-сервере разрешена аутентификация с использованием сертификата, то при попытке залогиниться с вводом имени и пароля пользователь увидит сообщение об ошибке. Единственный возможный вариант логина при таких настройках – если локальный сертификат SSH (публичный ключ) загружен в список разрешенных ключей (authorized_keys) на сервере, куда требуется залогиниться.При настройке в Veeam Backup & Replication 8.0 задания резервного копирования, в которое входит такой Linux-сервер, нужно будет указать соответствующий приватный ключ.

Как это работает в Veeam Backup & Replication v8


Итак, сперва создается пара RSA-ключей, и у вас получается два файла:
  • id_rsa – приватный ключ, его сохраняем на сервере резервного копирования. Путь к этому ключу нужно будет указать при конфигурации задания резервного копирования.
  • id_rsa.pub — публичный ключ, его нужно сохранить в файл authorized_keys того SSH-сервера (Linux ВМ), чью гостевую ОС вы планируете индексировать.

Кстати, в установочном каталоге Veeam присутствует PuTTYGen – его можно использовать для генерации приватных ключей PuTTY Private Key (PPK) для сервера резервного копирования Veeam Backup & Replication. Поддерживаются следующие форматы SSH-ключей: OpenSSH RSA, OpenSSH DSA, OpenSSL PEM, Open SSL PKCS#8 и SSH.com.

Более детальную информацию, а также описание работы с Credentials Manager – инструментом для централизованного управления настройками доступа в Veeam Backup & Replication можно найти здесь (на англ.яз.).

Настройки пользовательского доступа можно ввести и в ходе создания задачи резервного копирования или репликации. В мастере настройки задания резервного копирования для Linux ВМ доходим до шага Guest Processing, включаем опцию индексирования гостевой ОС; затем в секции задания настроек доступа нажимаем Add и из трёх представленных в списке способов выбираем Linux public key:
image
В открывшемся диалоге нужно указать, какому имени пользователя будет ставиться в соответствие наш ключ (например, root), и указать путь к приватному ключу, который вы до этого создали. Если при создании ключа использовалась кодовая фраза (passphrase), вводим её тоже.

image

После того, как вы указали ключ, можно проверить, сработает ли он при аутентификации – для этого после возвращения к шагу Guest Processing нажимаем Test Now и наблюдаем за процессом:
image

Эта кнопка реально полезна, т.к. при проверке ключа проверяется заодно и наличие всех компонентов, необходимых для индексирования гостевой ОС. Так, в примере выше использовалась CentOS в минимальной конфигурации, куда по умолчанию не входит mlocate, о чьем отсутствии и сообщила ошибка в сессии. Есть еще две необходимых утилиты – это gzip и tar.

Собственно, основную работу выполняет mlocate, которая ведет эффективный поиск файлов, используя не файловую систему, а индексную БД, а Veeam использует SSH-соединение для «выдачи указаний» этой утилите (стартовать, обновить базу с помощью updatedb, и т.д.). (В данном сценарии использовать соединение через VMware VIX не удастся – данная функциональность запланирована к реализации на будущее, а в текущей версии серверу резервного копирования необходим доступ к Linux ВМ по сети через SSH.)

Заметим, что поскольку обычным пользователям может не хватать прав для доступка к файлам и выполнения команд (в частности, индексная база закрыта для чтения обычными пользователями), то рекомендуется либо указывать в диалоге Credentials пользователя root, либо включать опцию Elevate account to root.

Таким образом, mlocate выдаст файлы, найденные по индексной БД, и метаданные (включая пути, время последнего обновления индекса, и др.), а tar и gzip соответственно сложат все это в один файл и аккуратно упакуют.

После того, как все необходимые компоненты установлены и тест на аутентификацию успешно пройден, можно перейти к завершающим шагам мастера настройки. И помним, разумеется, что указанные настройки будут применяться ко всем машинкам, включенным в задание – если только не указать иное для выбранной машины (так, индивидуальные настройки доступа к гостевой ОС можно ввести, нажав кнопку Credentials на соответствующем шаге мастера).

Во время выполнения задания резервного копирования в окне статистики будет выводиться подробная информация о ходе индексирования Linux ОС с использованием приватного ключа:
image
На скриншоте показаны этапы процесса (отмечены стрелками, сверху вниз):
  • Veeam коннектится к Linux ВМ через SSH, используя для логина приватный ключ.
  • Затем с помощью mlocate индексируется гостевая файловая система.
  • После этого с помощью tar и gzip создается компактный файл индекса GuestIndexData.tar.gz.
  • В конце работы индексный файл публикуется в каталог VBRCatalog – для того, чтобы пользователи могли выполнять поиск файлов для восстановления. (Подробнее о каталоге можно почитать здесь.)

Надеюсь, новые опции работы с виртуальными машинами под управлением Linux пригодятся вам или вашим коллегам. Однако это лишь первый из 8 рассказов, продолжение следует.

Дополнительная информация:


Tags:
Hubs:
+4
Comments 2
Comments Comments 2

Articles

Information

Website
veeam.com
Registered
Founded
Employees
1,001–5,000 employees
Location
Швейцария