SSH-аутентификация по ключам: настройка доступа без паролей

SSH-ключи вместо паролей: где ломается доступ к серверам

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

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

Перебор паролей дёшев для атакующего: десятки тысяч попыток за минуту по стандартному порту, слабые пароли поддаются ещё быстрее. Ограничение попыток снижает шум в журналах, но не закрывает вопрос — одна утёкшая пара «логин и пароль» открывает сервер целиком, вместе с ключами и данными внутри.

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

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

Что меняется после перехода на ключевую аутентификацию

Пароль — общий секрет: он утекает через переписку, оседает в истории команд и в скриптах развёртывания, а подбирается автоматическими сканерами за считанные часы. Как только в конфигурации сервера появляется запрет на вход по паролю, этот класс отказов уходит целиком — перебор и подстановка украденных учётных данных перестают работать. Клиент OpenSSH есть в любой актуальной ветке системы, отдельный агент разворачивать не нужно.

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

Ручная работа администраторов падает: тикеты «забыл пароль», плановая смена общего пароля по всей инфраструктуре и разбор блокировок после серии неудачных входов уходят из очереди задач. Остаётся одна операция — добавить или убрать ключ.

Ключ привязан к человеку, поэтому в журналах видно, кто именно открывал сессию, а не безликий общий логин. Дополнительно его ограничивают: разрешённые адреса, фиксированная команда при подключении, запрет проброса портов — доступ выдаётся ровно под ту задачу, для которой он нужен. За счёт этого управление доступом команды становится воспроизводимой процедурой, а безопасный доступ к серверам — проверяемым, а не договорным.

Варианты доступа: SSH-ключи, пароли и сертификаты

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

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

Как проходит внедрение ключевого доступа в инфраструктуру

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

1. Аудит доступа к серверам: собираем перечень хостов, учётных записей, источников подключения и текущих authorized_keys с отпечатками. Отдельно помечаем общие ключи, вход под root и записи, которые никто не может подтвердить.
2. Проектирование модели доступа: роли (администратор, выкладка, чтение логов), отдельный ключ на роль и на человека, единый бастионный узел для внешних подключений вместо прямых портов на каждом сервере.
3. Генерация и хранение ключей: современный алгоритм подписи, парольная фраза на приватной части, приватный ключ — только в защищённом хранилище, в реестр уходят публичные части и отпечатки.
4. Раскатка публичных ключей и конфигурации: authorized_keys через шаблоны и управление конфигурацией, в sshd_config — отключение паролей и входа root, ограничение алгоритмов и числа сессий. Применяем без перезапуска рабочих сервисов.
5. Проверка настройки доступа: тестовый вход по каждой роли, проверка отзыва ключа и реакции журналов, контроль, что старые способы входа закрыты, но аварийный канал доступен дежурному.
6. Передача ключей команде: выдача по защищённому каналу, готовый ssh_config с алиасами и бастионом, порядок ротации и отзыва, короткая инструкция для новых инженеров.
7. Регламент и сопровождение: срок жизни ключей, плановая ротация, чек-лист при смене роли или уходе сотрудника, реестр отпечатков как источник правды.

Контур считается сданным, когда новый инженер получает доступ по инструкции за минуты, а отзыв ключа закрывает вход на всех хостах одновременно.

Что остаётся у вас после настройки доступа

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

• Конфигурации серверов — sshd_config с отключённой парольной аутентификацией, ограничением по пользователям и группам, лимитом попыток и таймаутом сессии, в виде, который переносится в систему управления конфигурацией.
• Схема ключевого доступа — какие SSH-ключи куда ведут, где хранятся приватные части, какие узлы открыты напрямую, а какие доступны только через промежуточный хост.
• Регламент выпуска ключей — кто инициирует заявку, как формируется пара, где живёт приватный ключ, что фиксируется в запросе и кто подтверждает выдачу.
• Регламент отзыва — срок удаления записи из authorized_keys, порядок действий при увольнении и смене роли, проверка, что прежний ключ больше не даёт доступа.
• Документация для дежурной смены — типовые симптомы (отказ аутентификации, неверные права на каталог, переполнение журнала), что проверять первым делом и к кому обращаться при инциденте.
• Инвентаризация доступов — таблица «сотрудник — ключ — сервер — срок действия», по которой видно, у кого доступ есть и когда он должен закончиться.
• Точки мониторинга — какие события пишутся в журнал (успешные и неуспешные попытки, смена состава ключей), куда они уходят и по какому порогу срабатывает оповещение.

Кейс: как закрыли парольный вход в распределённой команде

До: 140 серверов и пароли в трёх местах

Команда из 60 инженеров на четырёх площадках держала около 140 серверов в трёх контурах. Вход был парольный: часть учёток лежала в общем файле, часть — у дежурных, у подрядчиков один служебный пользователь на всех. Выдача доступа занимала от нескольких часов до двух дней.

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

После: личный ключ и короткая подпись

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

Раскатку вели через Ansible: состав серверов и правила доступа описаны декларативно, новая машина получает ту же политику, что и остальные.

Что изменилось

Выдача доступа сократилась с дней до минут, отзыв — с «когда дойдут руки» до одного срока жизни сертификата. Парольный вход закрыт на всех серверах, включая стенды. Ушли три класса отказов: перебор паролей, общий служебный вход и живые доступы уволенных. По журналам теперь видно, кто и когда входил, — разбор инцидента опирается на записи, а не на показания.

Что делать, если парольный вход развёрнут на всех серверах

Да, порядок есть, и он не зависит от того, сколько серверов уже работает на паролях. Сначала ключи раскладываются на все машины, затем проверяется вход по ним, и только после этого пароль отключается — причём не везде одновременно. Базовое правило миграции: не бывает шага, после которого у вас остаётся единственный способ попасть на сервер.

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

Отдельно то, что нельзя делать одномоментно: запрет пароля сразу на всём парке, отключение аварийного доступа и совмещение миграции с обновлением системы. Аварийный вход через консоль провайдера проверяем до первых правок — иначе есть шанс остаться без доступа к машине. Финальный запрет парольного входа вводится по группам: сначала смотрим, кто и откуда заходил, закрываем остатки и только потом снимаем пароль на последней группе.

Сомнения и ограничения перед настройкой доступа

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

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

Как выдавать доступ служебным учётным записям и автоматизации?

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

А если часть систем не поддерживает ключи?

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

Как часто менять ключи и кто это контролирует?

Плановую смену привязываем к событиям: уход сотрудника, смена роли, компрометация хоста. Регламент фиксирует владельца ключа, срок жизни и порядок отзыва — иначе через полгода никто не скажет, чей ключ всё ещё открывает прод.

Обсудим доступ к серверам без паролей

Чтобы обсудить настройку доступа предметно, а не «на глазок», нужен срез вашего контура: что есть сейчас и каким он должен стать. Работаем с OpenSSH — эталонной реализацией, которая есть в любом современном дистрибутиве, так что привычный инструментарий менять не придётся. Ниже — перечень, которого достаточно, чтобы мы вернулись с оценкой работ по доступу и планом.

• Инвентарь. Сколько серверов и сред, какие операционные системы, осталось ли оборудование без обновлений.
• Кто и откуда подключается. Сотрудники и сервисы, статические адреса или динамические, вход напрямую или через промежуточный узел.
• Что с паролями сегодня. Общие учётные записи, ротация, где лежат приватные ключи и чем защищены — файл, аппаратный носитель, хранилище секретов.
• Права и роли. Кому нужен доступ к боевому контуру и административный вход, как разделены среды между командами.
• Автоматика. Сборочные задания, выкладка релизов, резервное копирование — где ключ постоянно живёт на сервере-исполнителе.
• Внешние исполнители и аудит. Кому выдаём временный доступ, как отзываем, нужны ли журналы входов с привязкой к человеку.
• Ограничения и окно работ. Что нельзя менять, есть ли тестовый контур для обкатки и когда допустимы изменения.

Из этих ответов собирается план: порядок этапов, какие файлы конфигурации и правила затрагиваем, как проверяем результат и как откатываемся, если доступ где-то потерян. Опишите задачу — вернёмся с оценкой и планом работ.