Пожалуй, ни один человек не может назвать себя сисадмином, если он не знает, что такое SSH, и не овладел хотя бы азами этого инструмента. SSH — это и ворота удаленного сервера, и ключ, открывающий эти ворота. Большинство сисадминов давно сделали шаг от использования пароля для аутентификации при соединении с сервером к паре криптографических ключей — публичному и закрытому. Этот небольшой шаг на самом деле был огромным прогрессом в обеспечении безопасности облачных служб.
Но жизнь на месте не стоит, и команда OpenSSH уже несколько лет назад представила новые мощные инструменты SSH, которые дают большую гибкость и удобство удаленного администрирования, особенно если у сисадмина в управлении много удаленных серверов. Один из таких инструментов — сертификаты SSH. Хотя они проще обычных сертификатов x509, почему‑то их проникновение в удаленное администрирование идет туго. Видимо, сказывается инерция мышления. А ведь что может быть красивее и удобнее: ты выпускаешь корневой сертификат CA, который и загружаешь на сервер. Всё, имея SSH-сертификат, удостоверенный этим СА, ты можешь заходить на удаленный сервер. А далее рассмотрим нюансы, которые могут сделать жизнь сисадмина — не в ущерб безопасности — легче и приятнее.
Итак, создадим наш CA. Для примера пусть это будет ключевая пара, в которой используется схема цифровой подписи типа Ed25519. С легкой руки американского криптографа Брюса Шнайера среди многих криптографов утвердилось стойкое подозрение, что Агентство национальной безопасности США (NSA) сделало закладку в стандартизованную Национальным институтом стандартов и технологий США (NIST) эллиптическую кривую P-256. Мы не можем знать наверняка, так ли это. Но этот предполагаемый backdoor потенциально ставит безопасность коммуникаций под угрозу. И тут очень кстати пришлась разработанная профессором Дэниелом Дж. Бернштейном эллиптическая кривая Curve25519. Она считается безопасной. По крайней мере, никто из серьезных криптографов насчет этой кривой сомнений не выражал. Вот и будем с ней работать дальше.
Генерируем пару ключей для CA по известной стандартной процедуре (не ленимся, устанавливаем пароль — здесь и далее):
$ ssh-keygen -C CA -t ed25519 -f ca_key
Получаем два файла: ca_key
и ca_key.
. Они и образуют наш CA. Закрытый ключ ca_key
прячем в надежном месте, а открытый ключ ca_key.
помещаем на удаленном сервере в /
и даем серверу команду доверять всем ключам, подписанным этим CA, добавив в конфигурационный файл сервера /
такую строку:
TrustedUserCAKeys /etc/ssh/ca_key.pub
А поскольку ранее мы положились на кривую Curve25519, то добавляем в файл еще и такие строки:
PubkeyAcceptedKeyTypes ssh-ed25519-cert-v01@openssh.comCASignatureAlgorithms ssh-ed25519
Не забываем перезагрузить SSH-сервер после каждого изменения конфигурации (здесь и далее):
$ sudo systemctl restart ssh.service
Далее по давно отработанному шаблону генерируем пару пользовательских ключей для аутентификации на сервере:
$ ssh-keygen -t ed25519 -f id_ed25519
и подписываем открытый ключ пользователя id_ed25519.pub:
$ ssh-keygen -s ca_key -I alex25 -n root id_ed25519.pub
В результате получаем собственно сертификат пользователя: id_ed25519-cert.
.
Опция -I
— это идентификатор ключа, он может быть любой цифро‑буквенной строкой, но лучше ее индивидуализировать, чтобы понимать, кто, когда и куда с таким идентификатором входил на сервер, так как в логах ID ключа всегда указывается.
Опция -n
задает принципала (о них ниже), в данном случае это root. Представленная схема сертификата самая простая, а потому не самая безопасная. Она позволяет владельцу такого ключа входить когда угодно и откуда угодно на любой сервер, доверяющий данному CA, с правами root без каких‑либо ограничений, а это плохо.
Изменить такое положение вещей можно, используя концепцию принципалов. Принципал в самом общем случае — это сетевой ресурс, который представляет вычислительный актор (компьютер, служба, процесс и подобное) или даже конкретного человека, инициирующего доступ к сетевым ресурсам и подтверждающего свою подлинность этим сетевым ресурсам. Далее будем рассматривать принципала в узком смысле как конкретного человека, имеющего SSH-сертификат.
Продолжение доступно только участникам
Материалы из последних выпусков становятся доступны по отдельности только через два месяца после публикации. Чтобы продолжить чтение, необходимо стать участником сообщества «Xakep.ru».
Присоединяйся к сообществу «Xakep.ru»!
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее
icoz
18.03.2021 в 21:10
Тема интересная, но по сути администрирования рассказано мало. Статья на тему «что можно», а не «это делается так, а вот это вот так…»
Интересно почитать конкретные примеры более сложных построений. Например, как сделать конфиг, соответствующий последней картинке.
Андрей Пархоменко
19.03.2021 в 07:34
Спасибо, совершенно согласен!
Однако, конкретных примеров сложных построений в сети уйма. Те, кто администрирует 100+ серверов и так все знают и давно используют.
Начинающие, и те, кто знал, но забыл, увидев самый простой пример, всё вспомнят и смогут сконфигурировать схему для своих пяти-десяти серверов. А на ограниченной журнальной площади дать примеры на все случаи жизни вряд ли возможно.
Удачи!
pretorianec
20.03.2021 в 18:03
https://engineering.fb.com/2016/09/12/security/scalable-and-secure-access-with-ssh/
ya
18.03.2021 в 23:00
тема так себе, этот зоопарк из DMZ выпускать ни в коем случае нельзя
Андрей Пархоменко
19.03.2021 в 07:43
Ох, смеялся над зоопарком, чуть утренний кофе не пролил на клавиатуру. Только Хакер имеет таких читателей, делающих замечательные постмодернистские комментарии!
Настоящий зоопарк вот здесь:
https://habr.com/ru/company/itsumma/blog/500828/
Недаром первый комментарий там был: «Статья о том, как подарить ключи от своего сервера левым конторам». И я бы согласился.
Моя цель была выпустить зоопарк на свободу из DMZ так, чтобы безопасностью не жертвовать ни на йоту.
Успехов!