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

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

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

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

Суть

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

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

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

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

Настройка, которую мы произвели в первой части позволяет заходить под любым пользователем на удаленный сервер. И более нигде прописывать публичный ключ пользователя не требуется. Ни в глобальном файле AuthorizedKeysFile, ни в локальных. В том числе, можно спокойно разрешить заходить под пользователем root. Только для этого нужно, чтобы была включена соответствующая опция в файле /etc/ssh/sshd_config:

PermitRootLogin     yes

Не забудьте перезапустить sshd перед тем, как проверять.

Самое главное они забыли!

Напомню, что передо мной стояла задача управлять учетными записями пользователей на серверах. Кому-то разрешать доступ к таким-то аккаунтам, другим – запрещать.

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

К несчастью, вопрос о том, как запрещать доступ к определенным учетным записям остался открытым. Настолько открытым, что сначала я долго не мог понять зачем это вообще нужно. Таким способом удобно раздавать доступ для серверов, демонов, утилит и т.д. Но передо мной стояла задача иного характера: управлять учетными записями людей. И при этом задавать легко и просто необходимые права для любых учетных записей. Да, решение оказалось не совсем подходящим. Но это только на первый взгляд!

Варианты конфигураций

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

AuthorizedPrincipalsFile /etc/ssh/authorized_principals

# ...

Match User root
    AuthorizedPrincipalsFile /etc/ssh/authorized_principals_root

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

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

Да-а-а, таким способом можно раздавать доступы на сервера. Это дело можно даже автоматизировать пятью строчками на баше или перле :-)

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

Ложка дегтя в бочке меда

Но это решает только половину задачи! Нам надо еще уметь отзывать сертификаты. Если вам это не нужно, то можно считать что это Happy End. Оказалась, что отзывать сертификаты можно только через утилиту ssh-keygen, и имея на руках публичный ключ пользователя, т.е. файл $HOME/.ssh/id_rsa.pub или серийный номер. О том, как это делается будет рассказано в следующей статье.

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

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

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

С другой стороны, если имя роли будет по факту определять имя пользователя, тогда можно забыть об этом и просто удалять не нужные имена из файла. Вопрос в том, когда наступит момент банальной человеческой ошибки: использовать то же самое имя, но для другого сертификата. Ну, можно использовать уникальные имена. Например, programmers/Vasiliy_Pupkin. И тогда, возможно, ошибиться будет намного сложнее.

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

Совместимость с другим ПО

К сожалению, заложенный функционал с версии openssh 5.6, выпущенной еще в 2010 поддерживается не всем клиентским ПО. Например, putty не понимает формат подписанных сертификатов. Возможно, для вас это будет неважно, но эта информация будет полезна остальным. Будьте внимательны и удостоверьтесь, что подписанные сертификаты будут работать у вас.

Выводы

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

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

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