С выходом Veeam Backup & Replication v8 пользователи принялись тщательно изучать новые функциональные возможности продукта. А поскольку «на вкус и цвет товарища нет», то каждый находит какие-то милые сердцу фичи лично для себя, причем это могут быть совсем скромные, «но оч-чень полезные подарки», то есть новые опции, которые сразу не бросаются в глаза, но над которыми кропотливо трудились разработчики. Так подобралась «великолепная восьмерка», может быть, не слишком нашумевших, но весьма полезных фич Veeam Backup & Replication v8. Мой сегодняшний рассказ про аутентификацию с использованием сертификата при доступе к гостевой ОС виртуальных машин под управлением Linux.
![image](https://habrastorage.org/r/w1560/files/d8f/81a/ede/d8f81aede78a4f33ac135a0158f22e0b.png)
Индексация гостевой файловой системы требуется для того, чтобы обеспечить пользователю удобный поиск и быстрое восстановление нужных файлов. В частности, Veeam Backup & Replication 8.0 поддерживает эту функциональность и для виртуальных машин под управлением Linux, предоставляя удобный веб-интерфейс Veeam Backup Enterprise Manager:
![image](https://habrastorage.org/r/w1560/files/998/4d0/d11/9984d0d1123f445f980ed0f62aaad766.png)
Соответствующие операции Veeam выполняет с помощью runtime-компонента, который запускается на гостевой ОС виртуальной машины с началом выполнения задания резервного копирования. Этот компонент координирует процессы при индексации (о них чуть позже), а по завершении задания прекращает работу. Для работы runtime-компонента на гостевой ОС и требуется аутентификация, для которой Veeam Backup & Replication 8 поддерживает теперь также использование сертификата (Linux public key).
Подробнее о индексации гостевой файловой системы см.здесь и здесь (на англ.яз.).
Те, кто работал с Linux-инфраструктурами, наверняка в курсе – редко кто логинится на Linux сервера, вводя имя пользователя и пароль. Причин тому несколько, среди них, в частности – отсутствие централизованного управления учетными записями. Да, кто-то использует Microsoft Active Directory через Kerberos, кто-то иные способы, но это отнюдь не массовое явление, и настройка и управление большим количеством учеток в немаленькой инфраструктуре может стать головной болью для того, кто за это отвечает.
Взять хотя бы пароли: все знают, что в целях безопасности следует использовать пароли достаточной сложности и регулярно их менять. Да на это же можно полжизни потратить! Кое-кто решает упростить задачу и использовать, скажем, никогда не меняющиеся пароли, или простые короткие пароли. Понятно, что жить становится легче, но безопасность при этом снижается. Помним еще, что кроме коммуникации «человек-компьютер» есть еще коммуникация «компьютер-компьютер», и чтобы обеспечить коммуникацию между серверами, следует хранить пароли там, где к ним был бы доступ у приложений и скриптов – при этом очень желательно в каком-то защищенном виде, а не в текстовом формате.
Из-за всего этого администраторы Linux-систем часто используют метод аутентификации с использованием сертификата, полностью отключая возможность логиниться с вводом имени и пароля. Идея состоит в том, чтобы пользователь (или сервер) использовал для доступа через SSH к удаленной машине сертификат, зарегистрированный на этой удаленной машине – что и позволяет получить авторизацию без необходимости ввода имени\пароля.
Этот сертификат нужно зарегистрировать всего один раз, после чего доступ будет предоставляться автоматически. Выдачу сертификатов также можно автоматизировать.
Если на Linux-сервере разрешена аутентификация с использованием сертификата, то при попытке залогиниться с вводом имени и пароля пользователь увидит сообщение об ошибке. Единственный возможный вариант логина при таких настройках – если локальный сертификат SSH (публичный ключ) загружен в список разрешенных ключей (authorized_keys) на сервере, куда требуется залогиниться.При настройке в Veeam Backup & Replication 8.0 задания резервного копирования, в которое входит такой Linux-сервер, нужно будет указать соответствующий приватный ключ.
Итак, сперва создается пара RSA-ключей, и у вас получается два файла:
Кстати, в установочном каталоге 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](https://habrastorage.org/r/w1560/files/76f/425/0a3/76f4250a3e5d4b2c9a668d1f84fa4e3c.png)
В открывшемся диалоге нужно указать, какому имени пользователя будет ставиться в соответствие наш ключ (например, root), и указать путь к приватному ключу, который вы до этого создали. Если при создании ключа использовалась кодовая фраза (passphrase), вводим её тоже.
![image](https://habrastorage.org/r/w1560/files/77d/3b3/91d/77d3b391d14a495daa0b9a04cd054c31.png)
После того, как вы указали ключ, можно проверить, сработает ли он при аутентификации – для этого после возвращения к шагу Guest Processing нажимаем Test Now и наблюдаем за процессом:
![image](https://habrastorage.org/r/w1560/files/d97/d30/0d7/d97d300d77f94a36a69b6cfcb1905c8c.png)
Эта кнопка реально полезна, т.к. при проверке ключа проверяется заодно и наличие всех компонентов, необходимых для индексирования гостевой ОС. Так, в примере выше использовалась CentOS в минимальной конфигурации, куда по умолчанию не входит mlocate, о чьем отсутствии и сообщила ошибка в сессии. Есть еще две необходимых утилиты – это gzip и tar.
Собственно, основную работу выполняет mlocate, которая ведет эффективный поиск файлов, используя не файловую систему, а индексную БД, а Veeam использует SSH-соединение для «выдачи указаний» этой утилите (стартовать, обновить базу с помощью updatedb, и т.д.). (В данном сценарии использовать соединение через VMware VIX не удастся – данная функциональность запланирована к реализации на будущее, а в текущей версии серверу резервного копирования необходим доступ к Linux ВМ по сети через SSH.)
Заметим, что поскольку обычным пользователям может не хватать прав для доступка к файлам и выполнения команд (в частности, индексная база закрыта для чтения обычными пользователями), то рекомендуется либо указывать в диалоге Credentials пользователя root, либо включать опцию Elevate account to root.
Таким образом, mlocate выдаст файлы, найденные по индексной БД, и метаданные (включая пути, время последнего обновления индекса, и др.), а tar и gzip соответственно сложат все это в один файл и аккуратно упакуют.
После того, как все необходимые компоненты установлены и тест на аутентификацию успешно пройден, можно перейти к завершающим шагам мастера настройки. И помним, разумеется, что указанные настройки будут применяться ко всем машинкам, включенным в задание – если только не указать иное для выбранной машины (так, индивидуальные настройки доступа к гостевой ОС можно ввести, нажав кнопку Credentials на соответствующем шаге мастера).
Во время выполнения задания резервного копирования в окне статистики будет выводиться подробная информация о ходе индексирования Linux ОС с использованием приватного ключа:
![image](https://habrastorage.org/r/w1560/files/b7b/e0d/46b/b7be0d46b5d24f2284ac56e59c28248a.png)
На скриншоте показаны этапы процесса (отмечены стрелками, сверху вниз):
Надеюсь, новые опции работы с виртуальными машинами под управлением Linux пригодятся вам или вашим коллегам. Однако это лишь первый из 8 рассказов, продолжение следует.
![image](https://habrastorage.org/files/d8f/81a/ede/d8f81aede78a4f33ac135a0158f22e0b.png)
Для чего нам нужен доступ к гостевой ОС на Linux ВМ
Индексация гостевой файловой системы требуется для того, чтобы обеспечить пользователю удобный поиск и быстрое восстановление нужных файлов. В частности, Veeam Backup & Replication 8.0 поддерживает эту функциональность и для виртуальных машин под управлением Linux, предоставляя удобный веб-интерфейс Veeam Backup Enterprise Manager:
![image](https://habrastorage.org/files/998/4d0/d11/9984d0d1123f445f980ed0f62aaad766.png)
Соответствующие операции 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](https://habrastorage.org/files/76f/425/0a3/76f4250a3e5d4b2c9a668d1f84fa4e3c.png)
В открывшемся диалоге нужно указать, какому имени пользователя будет ставиться в соответствие наш ключ (например, root), и указать путь к приватному ключу, который вы до этого создали. Если при создании ключа использовалась кодовая фраза (passphrase), вводим её тоже.
![image](https://habrastorage.org/files/77d/3b3/91d/77d3b391d14a495daa0b9a04cd054c31.png)
После того, как вы указали ключ, можно проверить, сработает ли он при аутентификации – для этого после возвращения к шагу Guest Processing нажимаем Test Now и наблюдаем за процессом:
![image](https://habrastorage.org/files/d97/d30/0d7/d97d300d77f94a36a69b6cfcb1905c8c.png)
Эта кнопка реально полезна, т.к. при проверке ключа проверяется заодно и наличие всех компонентов, необходимых для индексирования гостевой ОС. Так, в примере выше использовалась CentOS в минимальной конфигурации, куда по умолчанию не входит mlocate, о чьем отсутствии и сообщила ошибка в сессии. Есть еще две необходимых утилиты – это gzip и tar.
Собственно, основную работу выполняет mlocate, которая ведет эффективный поиск файлов, используя не файловую систему, а индексную БД, а Veeam использует SSH-соединение для «выдачи указаний» этой утилите (стартовать, обновить базу с помощью updatedb, и т.д.). (В данном сценарии использовать соединение через VMware VIX не удастся – данная функциональность запланирована к реализации на будущее, а в текущей версии серверу резервного копирования необходим доступ к Linux ВМ по сети через SSH.)
Заметим, что поскольку обычным пользователям может не хватать прав для доступка к файлам и выполнения команд (в частности, индексная база закрыта для чтения обычными пользователями), то рекомендуется либо указывать в диалоге Credentials пользователя root, либо включать опцию Elevate account to root.
Таким образом, mlocate выдаст файлы, найденные по индексной БД, и метаданные (включая пути, время последнего обновления индекса, и др.), а tar и gzip соответственно сложат все это в один файл и аккуратно упакуют.
После того, как все необходимые компоненты установлены и тест на аутентификацию успешно пройден, можно перейти к завершающим шагам мастера настройки. И помним, разумеется, что указанные настройки будут применяться ко всем машинкам, включенным в задание – если только не указать иное для выбранной машины (так, индивидуальные настройки доступа к гостевой ОС можно ввести, нажав кнопку Credentials на соответствующем шаге мастера).
Во время выполнения задания резервного копирования в окне статистики будет выводиться подробная информация о ходе индексирования Linux ОС с использованием приватного ключа:
![image](https://habrastorage.org/files/b7b/e0d/46b/b7be0d46b5d24f2284ac56e59c28248a.png)
На скриншоте показаны этапы процесса (отмечены стрелками, сверху вниз):
- Veeam коннектится к Linux ВМ через SSH, используя для логина приватный ключ.
- Затем с помощью mlocate индексируется гостевая файловая система.
- После этого с помощью tar и gzip создается компактный файл индекса GuestIndexData.tar.gz.
- В конце работы индексный файл публикуется в каталог VBRCatalog – для того, чтобы пользователи могли выполнять поиск файлов для восстановления. (Подробнее о каталоге можно почитать здесь.)
Надеюсь, новые опции работы с виртуальными машинами под управлением Linux пригодятся вам или вашим коллегам. Однако это лишь первый из 8 рассказов, продолжение следует.