Аутентификация на основе открытого ключа SSH имеет ряд недостатков и проблем, которые могут поставить под угрозу безопасность доступа к SSH в вашей организации. Мы подробно обсуждали эти недостатки в нашем предыдущем блоге: Ужесточение SSH-доступа с использованием недолговечных SSH-сертификатов.
Аутентификация на основе сертификатов SSH решает большинство этих проблем безопасности, упрощая при этом управление сертификатами и ключами.
В этой статье мы обсудим, как настроить и установить SSH сертификаты для SSH доступа к вашим серверам и облачным ресурсам.
Обзор:
Вот обзор того, что мы собираемся обсудить в этой статье.
-
Мы создадим два SSH Certificate Authorities(CA) — хост CA и пользовательский CA, чтобы подписывать хост-сертификаты SSH и пользовательские сертификаты соответственно. (Примечание: Вы можете создать один ЦС для подписи сертификатов пользователя и хоста. Но лучше держать их отдельно, чтобы можно было менять их по отдельности, когда того потребует ситуация).
-
Мы покажем, как настроить хост- и пользовательские машины на доверие сертификатам, выданным этими хост- и пользовательскими ЦС.
-
Мы создадим сертификат хоста SSH для каждого хоста и подпишем его с помощью закрытого ключа ЦС хоста.
-
Мы создадим сертификат пользователя SSH для каждого пользователя и подпишем его с помощью закрытого ключа ЦС пользователя.
-
Наконец, мы обсудим преимущества и недостатки использования аутентификации на основе сертификатов SSH.
Шаг 1 — Создание сертификатов ЦС
Прежде чем создавать сертификаты ЦС, нам нужна пара ключей SSH для работы. Как обычно, мы будем использовать инструмент ssh-keygen для генерации пары ключей SSH. Мы выполним следующий набор команд на сервере, назначенном в качестве ЦС.
User CA SSH key pair:
# ssh-keygen -t rsa -b 4096 -f ~/.ssh/ssh_user_ca
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/ssh_user_ca
Your public key has been saved in /root/.ssh/ssh_user_ca.pub
The key fingerprint is:
SHA256:ShpCF11/fYjujAVDYivNKpNM6QdVwh8Z9sX00PIspdo
The key's randomart image is:
+---[RSA 4096]----+
| .oooBo.o+. |
| +o*o* .o=o. |
| . = ..+.= o*+ .|
| . = o o. =o o. |
| . B + S oo. |
| . B . .=Z |
| . . . o |
| |
| |
+----[SHA256]-----+
Пара ключей SSH хоста ЦС:
# ssh-keygen -t rsa -b 4096 -f ~/.ssh/ssh_host_ca
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/ssh_host_ca
Your public key has been saved in /root/.ssh/ssh_host_ca.pub
The key fingerprint is:
SHA256:ShpCF11/fYjujAVDYivNKpNM6QdVwh8Z9sX00PIadsfj
The key's randomart image is:
+---[RSA 4096]----+
| .oooBo.o+. |
| +o*o* .o=o. |
| . = ..+.= o*+ .|
| . = o o. =o o. |
| . B + S oo. |
| . B . .=F |
| . . . o |
| |
| |
+----[SHA256]-----+
Мы запрашиваем ключ типа RSA с помощью флага -t, а длина ключа должна быть 4096 бит с помощью флага -b. Чем длиннее ключ, тем сложнее его взломать.
Настоятельно рекомендуется указывать кодовую фразу для закрытого ключа. Если неавторизованный пользователь завладеет закрытым ключом без парольной фразы, он сможет войти на любой сервер, который вы настроили с помощью соответствующего открытого ключа.
Приведенная выше команда создаст пару SSH — открытый ключ и закрытый ключ — в стандартной папке .ssh в вашем домашнем каталоге. Например: /home/bob/.ssh/.
Шаг 1a — Подписание сертификата хоста центра сертификации
Теперь, используя следующую команду, создадим сертификат центра сертификации хоста, используя открытый ключ хоста, и подпишем его, используя соответствующий закрытый ключ хоста, созданный в предыдущем шаге.
# ssh-keygen -s ~/.ssh/ssh_host_ca -I my-ca -h -n my-ca.example.com -V +52w ~/.ssh/ssh_host_ca.pub
Параметр -s указывает закрытый ключ хоста, который будет использоваться для подписания сертификата. Параметр -h используется для генерации сертификата типа хоста.
Опция -n устанавливает FQDN (Fully Qualified Domain Name) хоста в качестве принципалов в сертификате.
Параметр -V устанавливает срок действия сертификата.
В приведенном выше примере сертификат будет действителен с сегодняшнего дня и истечет через год (52 недели).
Вы можете проверить данные сертификата с помощью следующей команды:
# ssh-keygen -Lf ~/.ssh/ssh_host_ca-cert.pub
/root/.ssh/ssh_host_ca-cert.pub:
Type: ssh-rsa host certificate
Public key: RSA-CERT SHA256:7sCdBjn0...
Signing CA: RSA SHA256:7sCdBjn0... (using rsa-sha2-512)
Key ID: "my-ca"
Serial: 0
Valid: from 2022-02-12T10:09:00 to 2023-02-11T10:10:29
Principals:
my-ca.example.com
Critical Options: (none)
Extensions: (none)
Скопируйте сертификат хоста ЦС в папку /etc/ssh/ на сервере ЦС.
Шаг 2 — Распространение и доверие к сертификатам ЦС
Нам нужно скопировать сертификат пользовательского ЦС на все хосты в организации. Это необходимо для того, чтобы заставить хосты доверять центру подписи пользовательского сертификата.
Аналогично нам нужно скопировать сертификат CA хоста на все пользовательские машины. Это нужно для того, чтобы клиенты ssh на машинах пользователей доверяли центру подписи сертификата хоста.
Шаг 2a — Заставляем хосты доверять сертификату CA пользователя
# scp ~/.ssh/ssh_user_ca.pub root@host1.example.com:/etc/ssh/
Далее отредактируйте файл конфигурации SSH-сервера по адресу /etc/ssh/sshd_config и сделайте так, чтобы директива TrustedUserCAKeys указывала на открытый ключ ЦС пользователя (НЕ сертификат ЦС пользователя), который мы только что скопировали.
TrustedUserCAKeys /etc/ssh/ssh_user_ca.pub
Перезагрузите хост, чтобы изменения конфигурации вступили в силу.
# systemctl restart sshd
Шаг 2b — Заставляем клиентов доверять сертификату ЦС хоста
Для этого вам нужно скопировать содержимое сертификата ЦС хоста и добавить его в файл /etc/ssh/ssh_known_hosts, используя директиву @cert-authority, как показано ниже.
# cat /etc/ssh/ssh_host_ca-cert.pub
ssh-rsa AAAAHHNzaC1yc2EtY2.... root@example.com
Теперь скопируйте это содержимое в файл глобальной конфигурации SSH ssh_known_hosts во всех пользовательских системах.
# nano /etc/ssh/ssh_known_hosts
@cert-authority *.example.com ssh-rsa AAAAHHNzaC1yc2EtY2.... root@example.com
Приведенный выше символ подстановки *.example.com указывает пользовательским системам доверять сертификатам хоста, полученным от любых хостов в домене example.com, подписанным центром сертификации хоста.
Теперь, когда у нас есть сертификаты хостового и пользовательского ЦС, мы готовы выпустить сертификаты SSH для хостов и пользовательских машин, использующих их. Давайте сначала посмотрим, как выпустить сертификат хоста.
Шаг 3 — Создание сертификатов хоста SSH
Чтобы создать сертификат хоста, нам нужна пара ключей SSH. Давайте создадим ее, как обычно, с помощью команды ssh-keygen. Войдите на хост-машину, которой нужен сертификат, и выполните следующую команду.
# ssh-keygen -t rsa -b 4096 -f ~/.ssh/ssh_host
Приведенная выше команда сгенерирует открытый ключ (ssh_host.pub) и закрытый ключ (ssh_host) в папке .ssh в домашнем каталоге (/root/.ssh/).
Вы должны хранить закрытый ключ в безопасности в пределах хост-системы. Не следует копировать или переносить этот файл в любое другое место.
Мы скопируем только открытый ключ хоста на сервер CA с помощью команды scp, как показано ниже:
# scp /root/.ssh/ssh_host.pub root@my-ca:/root/tmp/
Затем создадим сертификат хоста на основе открытого ключа хоста и подпишем сертификат с помощью закрытого ключа хост-сервера CA.
# ssh-keygen -s ~/.ssh/ssh_host_ca -I host1@example.com -h -n host1.example.com -V +52w /root/tmp/ssh_host.pub
После подписания скопируйте сертификат SSH хоста (ssh_host-cert.pub) на хост-машину с помощью команды scp. Копировать сертификаты SSH безопасно, поскольку они являются общедоступными объектами и могут быть переданы кому угодно.
# scp /root/tmp/ssh_host-cert.pub root@host1.example.com:/etc/ssh/
Теперь настройте хост на использование подписанного сертификата хоста для любых соединений, поступающих от клиентов SSH. Отредактируйте файл /etc/ssh/sshd_config и установите директиву HostCertificate для указания на сертификат хоста, как показано ниже:
# nano /etc/ssh/ssh_config
…
HostCertificate /etc/ssh/ssh_host-cert.pub
…
Наконец, перезапустите SSH-сервер, чтобы изменения конфигурации вступили в силу.
# systemctl restart sshd
Шаг 4 — Создание сертификатов пользователей SSH
Сначала, как обычно, создадим пару ключей SSH для сертификата пользователя.
# ssh-keygen -t rsa -b 4096 -f ~/.ssh/ssh_user
Далее необходимо скопировать открытый ключ пользователя на сервер CA для его подписания.
# scp ~/.ssh/ssh_user.pub /root/tmp/.
Войдите на сервер ЦС и подпишите сертификат пользователя с помощью закрытого ключа пользователя ЦС, как показано ниже:
# ssh-keygen -s ~/.ssh/ssh_user_ca -I bob@example.com -n root -V +4w /root/tmp/ssh_user.pub
Безопасное копирование подписанного сертификата пользователя на компьютер пользователя.
# scp /root/tmp/ssh_user-cert.pub bob@user1.example.com:~/.ssh/.
Далее отредактируйте файл конфигурации клиента ssh /etc/ssh/ssh_config (глобальный файл конфигурации) или ~/.ssh/config (локальный файл конфигурации) в домашней директории пользователя и добавьте в него следующую строку, чтобы клиент SSH мог автоматически подбирать файл закрытого ключа и сертификат пользователя при аутентификации.
IdentityFile ~/.ssh/ssh_user
Обратите внимание, что директива IdentityFile указывает на закрытый ключ пользователя, а не на открытый ключ или сертификат.
Попробуйте войти на хост-машину с пользовательской машины, чтобы убедиться, что все настроено правильно и работает отлично.
$ ssh bob@host1.example.com
Удалите любой существующий открытый ключ для этого хоста из файла ~/.ssh/known_hosts на пользовательской машине, если это необходимо, чтобы предотвратить жалобы клиента SSH на изменение ключа хоста.
Открытый ключ хоста в файле ~/.ssh/known_hosts не имеет значения для аутентификации на основе сертификата SSH, поскольку для проверки подписи в сертификате хоста используется сертификат ЦС хоста.
Преимущества использования аутентификации на основе сертификата SSH:
-
SSH-сертификаты имеют срок действия, поэтому сертификаты пользователя и хоста рано или поздно истекают.
-
Сертификаты пользователей не нужно копировать на все хост-машины.
-
Для доступа к привилегированным ресурсам пользователям могут выдаваться недолговечные сертификаты SSH.
-
Больше никаких странных сообщений (о распознавании и принятии отпечатка ключа хоста), показываемых SSH-клиентом при первом входе на хост-машины.
-
При обнаружении компрометации безопасности аннулируйте старый ЦС, создайте новый ЦС и выдайте новые сертификаты хостам и пользователям. Это называется ротацией сертификатов.
Недостатки использования аутентификации на основе сертификатов SSH:
- Сертификаты необходимо периодически менять при правильном планировании и распределении ресурсов.
- Сертификаты пользователей с коротким сроком действия отлично подходят для привилегированного доступа к производственным ресурсам. Однако более частая выдача пользовательских сертификатов и их копирование на пользовательские машины — трудоемкий процесс.
Что такое решение BastionXP Bastion Host
Решение BastionXP Bastion Host со встроенным ЦС автоматизирует и упрощает процесс создания, подписания и распространения сертификатов. Оно также автоматизирует возможность ротации сертификатов, когда этого требует ситуация. SocketXP Bastion Host CA также выдает недолговечные пользовательские сертификаты конечным пользователям для доступа к облачным ресурсам или локальным серверам. Более того, решение легко работает с сервером и клиентами OpenSSH.
Таким образом, когда привилегированный пользователь покидает организацию, вам не нужно очищать открытые ключи или сертификаты на хост-машинах, поскольку мы не копируем их на хост-машины в первую очередь в рамках метода аутентификации на основе сертификатов SSH.
Более того, срок действия недолговечных сертификатов привилегированного пользователя истечет к тому времени, когда он покинет офис в последний рабочий день.
Узнать больше о решении SocketXP Bastion Host и начать бесплатную пробную версию можно здесь:
https://www.bastionxp.com