Про безопасную работу с ssh · Блог "Дети ОИТа"

Советы по безопасности использования SSH

Запрет на удалённый root - доступ.
Запрет подключения с пустым паролем или отключение входа по паролю.
Выбор нестандартного порта для SSH-сервера.
Использование длинных SSH2 RSA-ключей (2048 бит и более). Системы шифрования на основе RSA считаются надёжными, если длина ключа не менее 1024 бит.
Ограничение списка машин, с которых разрешён доступ
Запрет доступа с некоторых потенциально опасных адресов.
Отказ от использования распространённых или широко известных системных логинов для доступа по SSH.
Регулярный просмотр сообщений об ошибках аутентификации.
Использование ловушек, подделывающих SSH-сервис (honeypot).
Права файла authorized_keys должны быть 0600 и директории .ssh 0700.

Цепочка проверки соединения

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

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

А что насчёт проверки подлинности сервера?

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

Что такое публичный ключ хоста?

Каждый SSH-сервер имеет свою собственную пару ключей (ключи хоста). Публичный ключ хоста хранится на сервере и передаётся клиенту при первом подключении. Клиент сохраняет его в ~/.ssh/known_hosts, чтобы при последующих подключениях убедиться, что он соединяется с тем же самым сервером (защита от Man-in-the-Middle).
Публичный ключ хоста никак не связан с ключами пользователей, которые хранятся в authorized_keys.

Итог

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

Что происходит при краже приватного ключа клиента?

Если злоумышленник завладел вашим приватным ключом (например, id_rsa), он может использовать его для подключения к любому серверу, где соответствующий публичный ключ прописан в authorized_keys для какого-либо пользователя.
Сервер при этом остаётся тем же самым, его ключ хоста не меняется. Для клиента (злоумышленника) ключ хоста сервера будет именно таким, какой ожидается (если он уже есть в known_hosts или если пользователь согласится принять его). Таким образом, соединение будет успешно установлено, и злоумышленник получит доступ.

Какие контрмеры можно применить?

Удалить скомпрометированный публичный ключ из authorized_keys на всех серверах. Например так:

ansible all -m authorized_key -a "user=admin key='содержимое_скомпрометированного_ключа' state=absent"

Или все ключи:

ansible all -m copy -a "dest=/home/admin/.ssh/authorized_keys content='' owner=admin group=admin mode=0600"

Сгенерировать новую пару ключей и добавить новый публичный ключ на серверы. Добавляем на удаленные машины. p.s Внутри кавычек key=’’ можно вручную вставить pub ключ.

ansible all -m authorized_key -a "user=admin key='{{ lookup('file', '~/.ssh/id_rsa.pub') }}'" -k

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

Опция expiry-time (дата истечения ключа) в authorized_keys

expiry-time="2026-12-31 23:59:59" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ... user@host

Плюсы:

Очень просто, не требует изменения конфигурации SSH-сервера
Можно задать для каждого ключа индивидуально
Минусы:
Ненадежно, если пользователь имеет доступ на запись своего authorized_keys — он может просто удалить эту опцию
Не защищает от ситуации, когда ключ скомпрометирован и злоумышленник тоже может его отредактировать

🔐 Что такое парольная фраза?

При генерации SSH-ключа (например, ssh-keygen) вас спрашивают: «Enter passphrase (empty for no passphrase):». Если вы её вводите, приватный ключ сохраняется на диске в зашифрованном виде. Ключ шифруется с использованием вашей парольной фразы (обычно симметричным шифром, например AES).

🛡️ От чего защищает парольная фраза?

Если злоумышленник украдёт файл вашего приватного ключа (например, ~/.ssh/id_rsa), он не сможет сразу им воспользоваться — ему потребуется подобрать или узнать вашу парольную фразу. Без неё файл ключа бесполезен.
Таким образом, парольная фраза — это последний рубеж защиты в случае физической кражи носителя (ноутбука, флешки) или если кто-то временно получил доступ к вашим файлам.

⚠️ Ограничения парольной фразы

Атака на агента. Если вы один раз ввели парольную фразу и добавили ключ в SSH-агент (ssh-add), ключ хранится в памяти агента в расшифрованном виде. Если злоумышленник получит доступ к вашему сеансу (например, через вредоносное ПО с правами вашего пользователя), он сможет использовать агента для подключения к серверам, даже не зная парольной фразы.
Кейлоггеры и перехват ввода. Если на вашей машине есть вредоносное ПО, которое записывает нажатия клавиш, парольная фраза может быть перехвачена в момент ввода.
Не защищает от подбора слабой фразы. Если парольная фраза короткая или словарная, злоумышленник может попытаться подобрать её офлайн (если у него есть файл ключа).