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

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

Список возможных действий над подписанными сертификатами

Напомню, что вы можете управлять подписанными ключами как на целевом сервере, так и со своей машины.

Добавление пользовательского ключа

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

Необходимо:

  • Публичный и приватный ключи CA
  • Публичный ключ пользователя

Комманда:

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

Также можно воспользоваться опцией -z, которая задает серийный номер. Номера начинаются с нуля. Я бы отдал нулевой номер сертификату сервера. А что если серверов больше чем один, а CA один единственный на все сервера? Пусть каждый выберет свою любимую нумерацию.

Отзыв сертификата

Необходимо:

  • Публичный и приватный ключи CA
  • Публичный ключ пользователя или серийный номер

Комманда:

# ssh-keygen -k                         \ # Сгенерировать KRL файл 
             -f /etc/ssh/revoked_keys   \ # Путь к KRL файлу
             /home/test/.ssh/id_rsa.pub   # Публичный ключ пользователя

Если при создании подписанного сертификата использовалась опция -z, которая задает серийный номер сертификата, то можно просто его указать. Например, ниже отзывается сертификат с серийным номером 42:

# ssh-keygen -k                         \ # Сгенерировать KRL файл 
             -f /etc/ssh/revoked_keys   \ # Путь к KRL файлу
             42                           # Серийный номер

Управление ролями

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

Шаблонов может быть два:

  • По умолчанию разрешено все.
  • По умолчанию запрещено все.

Шаблон: разрешено все

В первой статье был рассмотрен этот вариант. Теперь надо ограничить доступ к определенным аккаунтам на сервер. В моем случае, это пользователи root и mysql.

AuthorizedPrincipalsFile /etc/ssh/authorized_principals_all

Match User root
    AuthorizedPrincipalsFile /etc/ssh/authorized_principals_root

Match User mysql
    AuthorizedPrincipalsFile /etc/ssh/authorized_principals_mysql

В файле authorized_principals_all я добавил все существующие роли/пользователей (об именовании ролей читайте в предыдущей статье). Этим пользователям разрешено заходить под всеми учетными записями, кроме root и mysql, для которых я переопределил файлы ролей: authorized_principals_root и authorized_principals_mysql, соответственно.

Шаблон: запрещено все

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

AuthorizedPrincipalsFile %h/.ssh/authorized_principals

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

Второй вариант похож на шаблон “все разрешено”:

# This line may be commented
# Default value 'none' that's means 
# this functionality is disabled.
AuthorizedPrincipalsFile /etc/ssh/authorized_principals_none

Match User root
    AuthorizedPrincipalsFile /etc/ssh/authorized_principals_root

Match User mysql
    AuthorizedPrincipalsFile /etc/ssh/authorized_principals_mysql

В файле authorized_principals_none мы никого не прописываем. Также эту строчку можно вообще исключить (но не во всех версиях задано значение по умолчанию, будьте внимательны). В файлах пользовательских ролей для root и mysql (authorized_principals_root и authorized_principals_mysql, соответственно) мы укажем только те роли, которые имеют доступ.

Шаблон: комбинирование

Можно догадаться, что также возможно скомбинировать подходы, описанные выше. Однако, в один прекрасный момент можно и запутаться, если серверов, аккаунтов и/или ролей слишком много.

По этой причине неплохо было бы как-то это дело автоматизировать. Во-первых, не хочется самому запоминать связки пользователь <=> публичный ключ/серийный номер. Во-вторых, хочется держать все конфигурации в одном месте и иметь возможность их просматривать/редактировать одним движением.

Скрипт ssh-ca.pl

Данный скрипт позволяет делать все действия над подписанными сертификатами. Написан на Perl, минимум зависимостей, прост в обращении.

Концепция

Предполагается, что скрипт будет использоваться на той же машине, где находятся публичный и приватный ключи CA. Вопросами копирования с машин предоставляется на усмотрение системного администратора. Тут вход могут идти самые разнообразные средства: rsync, chief, puppet, scp и т.п.

Что делает скрипт?

В “обязанности” скрипта входят:

  • Человек для модификации прав должен использовать лишь имя пользователя (предполагается настоящее). Хотя может быть задано абсолютно любым, например, никнеймы также годятся.
  • Запомнить серийные номера и публичные ключи пользователей.
  • Запомнить для какого сервера и для какого пользователя куда выдан доступ.

Установка и использование

Установите JSON::XS и Digest::MD5. Сделать это можно как с помощью средств вашего дистрибутива (модули весьма распространены) или через консоль cpan:

$ perl -MCPAN -e 'CPAN::Shell->install("JSON::XS");'
$ perl -MCPAN -e 'CPAN::Shell->install("Digest::MD5");'

Скачайте архив и запустите вывод справки:

$ tar xzvf ssh-ca-0.02.tar.gz
$ cd ssh-ca-0.02
$ perl bin/ssh-ca.pl --help

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

$ chmod +x bin/ssh-ca.pl
$ ./bin/ssh-ca.pl --help

Литература и ссылки

  1. Managing SSH Keys for Automated Access - Current Recommended Practice является черновиком RFC, в котором рассказывается об автоматизации доступа по SSH.

  2. Using a CA with SSH содержит краткую справку по командам (там есть логические ошибки).

  3. Вопрос по AuthorizedPrincipalsFile в openssh 5.6 дает ответ о формате файла AuthorizedPrincipalsFile.