Создание центра сертификации SSH для аутентификации хостов и клиентов на сервере Ubuntu

Ubuntu | Amber | Комментировать запись

Для настройки большого количества серверов понадобится множество пользователей, а это усложняет управление инфраструктурой по SSH.

В таком случае можно обратиться к средству централизованной аутентификации (например, LDAP), но иногда цель не оправдывает таких ресурсных затрат.

SSH позволяет создавать собственные центры сертификации (certificate authority, или CA) для авторизации серверов и клиентов. При помощи этой системы хост может аутентифицироваться на клиенте, избежав предупреждений системы. Также можно аутентифицировать клиента на хосте; для этого достаточно зарегистрировать один SSH-ключ.

Данное руководство поможет выполнить такую настройку.

Примечание: Для выполнения руководства нужно иметь три сервера Ubuntu 12.04. один из них будет использоваться как хост, второй – как клиенты, третий – как CA.

Настройка сертификатов хоста

Для начала нужно подготовить сертификаты, при помощи которых сервер будет подключаться к клиенту без запроса учётных данных.

Запустите машину, которая будет использоваться как СА; в данном руководстве она условно называется auth.example.com.

Генерирование ключей

Для начала нужно создать ключ RSA. Откройте сессию любого пользователя (лучше всего – root) и создайте ключи server_ca и server_ca.pub в домашнем каталоге.

Примечание: Условные имена файлов в данном руководстве отражают их предназначение. Такой подход к наименованию файлов очень удобен.

cd ~
ssh-keygen -f server_ca

Программа предложит установить фразовый пароль для ключей (злоумышленник не сможет воспользоваться ключами, не зная этого пароля). После этого в домашнем каталоге будет создан закрытый и открытый ключ:

ls
server_ca   server_ca.pub

Подпись ключей хоста

Для начала нужно подписать ключ СА. Для этого используется следующий синтаксис:

ssh-keygen -s signing_key -I key_identifier -h -n host_name -V +52w host_rsa_key

Рассмотрим его подробнее:

• -s: этот флаг задаёт закрытый ключ, при помощи которого будут подписаны остальные ключи.
• -I: эта опция задаёт имя сертификата, которое необходимо для логирования.
• -h: указывает, что ключ принадлежит хосту, а не клиенту.
• -n: имя хоста или пользователя, связанного с сертификатом.
• -V: задаёт срок действия сертификата; в данном примере сертификат будет действителен в течение 52 недель.

После всех этих аргументов нужно указать сам ключ.

В данном случае команда для подписи ключа RSA будет иметь следующий вид (откорректируйте её, указав свои данные):

ssh-keygen -s server_ca -I host_auth_server -h -n auth.example.com -V +52w /etc/ssh/ssh_host_rsa_key.pub
Signed host key /etc/ssh/ssh_host_rsa_key-cert.pub: id "host_auth_server" serial 0 for auth.example.com valid from 2014-03-20T12:25:00 to 2015-03-19T12:26:05

Как указано в выводе, сертификат действителен в течение одного года. Он находится в том же каталоге, что и ключ сервера, и называется ssh_host_rsa_key-cert.pub.

Теперь можно подписать ключ для сервера. Скопируйте ключ сервера (в руководстве она называется sshserver.example.com):

cd ~
scp root@sshserver.example.com:/etc/ssh/ssh_host_rsa_key.pub .

При помощи этого файла можно создать сертификат согласно изложенным выше инструкциям. Откорректируйте данные в команде и запустите её:

ssh-keygen -s server_ca -I host_sshserver -h -n sshserver.example.com -V +52w ssh_host_rsa_key.pub
Signed host key ssh_host_rsa_key-cert.pub: id "host_sshserver" serial 0 for sshserver.example.com valid from 2014-03-20T12:40:00 to 2015-03-19T12:41:48

Скопируйте сгенерированный файл сертификата обратно на хост.

scp ssh_host_rsa_key-cert.pub root@sshserver.example.com:/etc/ssh/

После этого можно удалить открытый ключ и сертификат сервера с машины СА.

rm ssh_host_rsa_key.pub ssh_host_rsa_key-cert.pub

Теперь сертификаты подписаны. Нужно только настроить их поддержку.

Поддержка сертификатов

Теперь нужно сообщить серверам auth.example.com и sshserver.example.com о новых сертификатах.

На обеих машинах для этого следует отредактировать главный конфигурационный файл демона SSH, sshd_config.

Примечание: Не спутайте файл sshd_config с файлом ssh_config.

sudo nano /etc/ssh/sshd_config

Найдите строку HostCertificate (или добавьте её в конец файла, если такой строки нет) и укажите в ней путь к сертификату:

HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub

Сохраните и закройте файл.

Перезапустите SSH, чтобы обновить настройки.

sudo service ssh restart

Примечание: Эти настройки нужно повторить на всех серверах, которые должны поддерживать сертификат.

Теперь серверы поддерживают новые сертификаты. Но клиент пока что не знает, как проверить  сертификаты серверов.

Перейдите на клиентскую машину (она называется client.example.com) и откройте (или создайте) файл:

nano ~/.ssh/known_hosts

Содержимое этого файла рекомендуется удалить. После этого нужно добавить открытый ключ, при помощи которого можно проверить подлинность предоставляемого закрытого ключа. Строка должна начинаться с @cert-authority, а после включать в себя домен и открытый ключ СА.

На машине СА открытый ключ можно узнать таким образом:

cat ~/server_ca.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCxC+gikReZlWEnZhKkGzhcNeRD3dKh0L1opw4/LQJcUPfRj07E3ambJfKhX/+G4gfrKZ/ju0nanbq+XViNA4cpTIJq6xVk1uVvnQVOi09p4SIyqffahO9S+GxGj8apv7GkailNyYvoMYordMbIx8UVxtcTR5AeWZMAXJM6GdIyRkKxH0/Zm1r9tsVPraaMOsKc++8isjJilwiQAhxdWVqvojPmXWE6V1R4E0wNgiHOZ+Wc72nfHh0oivZC4/i3JuZVH7kIDb+ugbsL8zFfauDevuxWeJVWn8r8SduMUVTMCzlqZKlhWb4SNCfv4j7DolKZ+KcQLbAfwybVr3Jy5dSl root@auth

Строка в файле ~/.ssh/known_hosts будет выглядеть так:

@cert-authority *.example.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCxC+gikReZlWEnZhKkGzhcNeRD3dKh0L1opw4/LQJcUPfRj07E3ambJfKhX/+G4gfrKZ/ju0nanbq+XViNA4cpTIJq6xVk1uVvnQVOi09p4SIyqffahO9S+GxGj8apv7GkailNyYvoMYordMbIx8UVxtcTR5AeWZMAXJM6GdIyRkKxH0/Zm1r9tsVPraaMOsKc++8isjJilwiQAhxdWVqvojPmXWE6V1R4E0wNgiHOZ+Wc72nfHh0oivZC4/i3JuZVH7kIDb+ugbsL8zFfauDevuxWeJVWn8r8SduMUVTMCzlqZKlhWb4SNCfv4j7DolKZ+KcQLbAfwybVr3Jy5dSl root@auth

Сохраните и закройте файл.

Теперь при подключении сервера к клиенту система не будет спрашивать, можно ли доверять этому серверу, поскольку его сертификат подписан СА.

Настройка ключей пользователей

Теперь нужно настроить ключи для пользователей, при помощи которых они смогут подключаться к серверам.

Этот процесс, как и в предыдущем разделе, начинается с машины СА. Создайте новый набор ключей.

ssh-keygen -f users_ca

Установите пароль для ключей, чтобы защитить их от злоумышленников.

Настройка серверов для поддержки сертификатов пользователей

После этого нужно скопировать открытый ключ на каждый сервер, к которому будет подключаться пользователь.

scp users_ca.pub root@sshserver.example.com:/etc/ssh/

Затем отредактируйте на сервере настройки демона SSH, чтобы он запрашивал ключ.

Перейдите на машину sshserver.example.com и откройте файл:

sudo nano /etc/ssh/sshd_config

В конец файла, под строкой HostCertificate, нужно добавить следующую строку, которая указывает путь к скопированному файлу:

TrustedUserCAKeys /etc/ssh/users_ca.pub

После этого нужно перезапустить демон SSH:

sudo service ssh restart

Подпись ключей пользователя

Теперь серверы принимают ключи пользователей users_ca. Нужно подписать их ключи.

Сначала нужно скопировать ключ клиента на машину СА. Перейдите на машину СА и введите:

cd ~
scp username@client.example.com:/home/username/.ssh/id_rsa.pub .

Переместив ключи на машину, можно подписать их. Для этого используется следующий синтаксис (вместо username укажите имя пользователя, которому будут принадлежать ключи):

ssh-keygen -s users_ca -I user_username -n username -V +52w id_rsa.pub
Signed user key id_rsa-cert.pub: id "user_username" serial 0 for username valid from 2014-03-20T14:45:00 to 2015-03-19T14:46:52

Программа запросит пароль users_ca. После этого в каталоге появится файл id_rsa-cert.pub, который нужно переместить обратно на клиент:

scp id_rsa-cert.pub username@client.example.com:/home/username/.ssh/

Теперь при подключении к sshserver.example.com с клиента не будут запрашиваться учётные данные.

Заключение

Теперь вы можете создать гибкую систему аутентификации серверов и клиентов.