О доверенных сертификатах в Openssh. Часть 1.

В opensshd (далее просто sshd) имеется возможность использования доверенных сертификатов. Это похоже на подписанные сертификаты в SSL/TLS, однако, есть несколько больших различий. Далее будет рассказано о подписанных сертификата SSH, их назначение, а также описано применение в действительности.

Продолжение:

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

Введение

Началось все с того, что потребовалось быстро и легко управлять доступом ко множеству машин, используя возможности самого sshd, а если что-то не получится перейти к более сложным решениям, таким как kerberos, sssd, freeipa.

Прежде чем перейти к описанию настройки, я хочу рассказать и показать как работает доверенные сертификаты в sshd. Как и в SSL/TLS, вам потребуется создать публичный и приватный ключи CA (Центра Сертификации). Затем подписать публичные ключи для сервера и клиентских машин. На текущий момент подписывать другие CA невозможно, это одно из отличий от SSL/TLS. После этого необходимо перенастроить sshd, предоставить подписанные ключи клиентам, и можно начинать работать по данной схеме. Какие возможности дает такая конфигурация, спросите вы?

  • Можно запретить использование неподписанных ключей для всех учетных записей.
  • Управление доступом осуществляется через удобно-читаемые заданные роли (principals).
  • Подписанные сертификаты могут иметь ограничение по времени действия.
  • Подписанные сертификаты можно отзывать в любой момент времени.

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

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

Требования

Данный функционал будет работать только, если версия openssh равна 5.6 или выше. Например, Debian Squeeze имеет версию 5.5 и описанный ниже функционал работать не будет (как у клиента, так и на сервера). Чтобы узнать версию ssh достаточно выполнить:

$ ssh -V

Настройка

Замечание. Необходимые действия по подписыванию сертификатов можно производить как на своей рабочей машине, так и прямо на удаленном сервере. Как и в случае SSL/TLS, приватный ключ CA должен храниться в целостности и сохранности, вдали от посторонних глаз. Публичный ключ CA может понадобиться клиентским машинам, но я пока не сталкивался с подобным (не смотря на то, что в Интернет говорят обратное). Я описываю все действия, которые выполняются непосредственно на удаленном сервере из под пользователя root.

Создание ключа CA

Следующая команда сгенерирует приватный /etc/ssh/ca и публичный /etc/ssh/ca.pub ключи центра сертификации.

# ssh-keygen -f /etc/ssh/ca

Подписывание ключа сервера

Чтобы подписать ключ сервера нужно указать специальный ключ -h, указать файл с приватным ключем CA и указать файл с публичным ключом хоста.

ssh-keygen  -h                              \ # Подписываем ключ сервера
            -s /etc/ssh/ca                  \ # Ключ CA
            -I "host key"                   \ # Идентификатор (все что угодно)
            -n "$(hostname),$(hostname --fqdn),$(hostname -I|tr ' ' ',')" \ # Имя роли
            /etc/ssh/ssh_host_rsa_key.pub     # Публичный ключ сервера

В результате получим подписанный сертификат /etc/ssh/ssh_host_rsa_key-cert.pub.

Подписывание пользовательского ключа

Пользовательский ключ, в нашем случае, мы сгенерируем самостоятельно для пользователя test. Вы можете взять готовый, расположен он по умолчанию в $HOME/.ssh/id_rsa.pub.

$ ssh-keygen -t rsa -q
Enter file in which to save the key (/home/test/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again:

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

# ssh-keygen -s /etc/ssh/ca                 \ # Ключ CA
             -I "test user key"             \ # Идентификатор (все что угодно)
             -V -5:+2w                      \ # Срок действия ключа 2 недели
             -n test                        \ # Имя роли пользователя
             /home/test/.ssh/id_rsa.pub       # Публичный ключ пользователя

Напомню, что если вы делаете на своей машине и имеется удаленный сервер, который надо настроить, то все, что нужно это иметь на руках ключи CA, а также публичный ключ пользователя и/или публичный ключ сервера (см. выше).

Таким образом, получим подписанный публичный ключ пользователя /home/test/.ssh/id_rsa-cert.pub.

Изменения конфигурации sshd

Осталось изменить конфигурацию для sshd. Вносим следующие изменения в файле /etc/ssh/sshd_config.

AuthorizedPrincipalsFile    /etc/ssh/authorized_principals
TrustedUserCAKeys           /etc/ssh/ca.pub
RevokedKeys                 /etc/ssh/revoked_keys

Поясню вкратце:

  • RevokedKeys указывает на список недействительных пользовательских ключей.
  • TrustedUserCAKeys указывает на список публичных ключей CA (в нашем случае он единственный).
  • AuthorizedPrincipalsFile содержит список ролей, которым разрешен доступ на сервер.

Теперь подробнее о каждом в отдельности. Формат файла RevokedKeys я пока не могу описать. Он заполняется только через команду ssh-keygen. Описание того, как добавлять недействительные сертификаты я расскажу в третьей статье.

Формат файла TrustedUserCAKeys чем-то похож на формат файлов $HOME/.authorized_keys (думаю, с ним вы уже знакомы). На каждой строчке должен содержаться публичный ключ CA.

Формат файла AuthorizedPrincipalsFile является упрощенным вариантом $HOME/.authorized_keys. На каждой строчке должно содержаться точно такое же имя роли, которое использовалось при подписании сертификата (опция -n для ssh-keygen). Перед именем роли можно задавать различные опции. В нашем случае в файл /etc/ssh/authorized_principals следует добавить всего одну строчку:

# echo "test" >> /etc/ssh/authorized_principals

После проделанного, вы должны убедиться, что все сделали верно:

  • Изменили конфигурацию в файле sshd_config
  • Добавили имя роли в файл AuthorizedPrincipalsFile
  • Скопировали подписанный ключ на машину пользователя

Проверка работоспособности

Я использую openssh как в качестве сервера, так и в качестве клиента. Поэтому в нем практически ничего не надо настраивать. В частности, если вы делали как было описано выше, то в директории /home/test/.ssh будут файлы со следующими именами:

id_rsa
id_rsa-cert.pub
id_rsa.pub

Также не забудем перезапустить sshd:

# /etc/init.d/sshd restart

Или, если у вас дистрибутив Fedora, RHEL/Centos 6+, Arch Linux или иной, работающий с systemd:

# systemctl restart sshd

Осталось зайти на сервер как обычно:

$ ssh localhost

Особенности и выявление ошибок

Во-первых, следует обратить внимание на экранирование специальных символов (например, “/”, “@”), когда задаете имя роли с помощью команды ssh-keygen. Это зависит от используемого шелла. Файл AuthorizedPrincipalsFile содержит имена как есть, т.е. без экранирования.

Во-вторых, если по каким-либо причинам, вас не пускает на сервер, то сперва надо убедиться что права на файлы и директории у клиента и сервера выставленны корректно. На директорию 0700, на файлы 0600.

Если вы забудете добавить имя роли или укажете его отличным от того, что указали при подписывании клиентского сертификата, то sshd сообщит вам об этом в логе:

Nov 19 17:13:44 gw sshd[2020]: error: Certificate does not contain an authorized principal

И главное, указывать публичный ключ клиента нигде больше не следует! Ни в каких файлах. Вообще. Просто отдали подписанный сертификат обратно клиенту и на этом дело сделано.

Продолжение следует

Это был лишь первый этап по конфигурации sshd с использованием доверенных сертификатов. Мы рассмотрели какие возможности перед нами открываются и настроили базовую конфигурацию sshd. В следующей статье будут рассмотренны случаи, где данная конфигурация будет полезна и в чем отличие от обычных сертификатов в плане управления и использования.