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

Для чего и кому

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

Кого это касается

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

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

Что это меняет для бизнеса

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

Приоритет

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

Что понадобится

Нужна учётная запись на сервере, с которой вы уже заходите по паролю, и права администратора для изменения конфигурации. На вашем компьютере должен быть клиент OpenSSH (команда ssh из перечня man-страниц OpenSSH).

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

Держите открытыми man-страницы ssh-keygen(1), ssh-agent(1), ssh-add(1) и sshd_config(5) на той же странице документации. Конкретные команды и названия параметров всегда сверяйте с документацией той версии OpenSSH, которая установлена у вас.

Шаги

1. Создайте пару ключей на своём компьютере инструментом ssh-keygen. Тип ключа и параметры защиты выберите по man-странице ssh-keygen(1) и политике вашей компании. Проверка: у вас есть две части ключа, закрытая и открытая, и вы их различаете. Закрытая остаётся только на вашем компьютере и никому не передаётся.
2. Добавьте открытый ключ на сервер способом, который описан в документации вашей версии OpenSSH и дистрибутива. Передаётся только открытая часть. Проверка: в списке разрешённых ключей вашей учётной записи на сервере есть запись именно открытого ключа, по одной на каждого человека.
3. Проверьте вход по ключу, не закрывая текущий сеанс. Откройте новое окно терминала и подключитесь командой ssh. Проверка: вход выполнен без пароля учётной записи. Если клиент по-прежнему запрашивает пароль, ключ не подхвачен: вернитесь к шагу 2 и дальше не переходите.
4. При необходимости настройте ssh-agent: это агент аутентификации, который может хранить закрытые ключи, а ssh-add добавляет ключи в него. Проверка: повторный вход в том же сеансе работы проходит без повторного ввода защиты ключа. На общих компьютерах после работы не оставляйте агент с загруженными ключами.
5. Отключите парольный вход в конфигурации демона sshd. Сначала сохраните копию файла конфигурации, затем в man-странице sshd_config(5) найдите параметр, отвечающий за парольную аутентификацию, и измените его. Примените изменение так, как это предусмотрено в вашем дистрибутиве. Проверка: в новом окне вход по ключу работает, а попытку войти только с паролем сервер отклоняет. Первое окно всё это время остаётся открытым.
6. Запишите, чей это ключ, и определите порядок отзыва. Заведите простой список: имя сотрудника, дата добавления, серверы. Проверка: каждая запись в списке ключей на сервере соответствует человеку из списка, а в процедуре увольнения или завершения сотрудничества есть пункт «удалить ключи».

Как проверить результат

Итоговая проверка состоит из трёх действий. Войдите на сервер новым сеансом по ключу. Попробуйте зайти только с паролем и убедитесь, что сервер отказывает. Сравните фактическое поведение с тем, что описано для вашего параметра в sshd_config(5): проверять нужно реальным входом, а не только текстом файла.

Отдельно просмотрите журнал аутентификации сервера: успешные входы должны идти по ключу, а попытки по паролю не должны заканчиваться входом. Если в компании есть автоматизация (скрипты, резервное копирование, система развёртывания), запустите её вручную и убедитесь, что она не зависела от пароля. Детали настроек ищите в документации OpenSSH для вашей версии.

Типичные ошибки

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

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

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

Если в вашей компании нет человека, который следит за доступами к серверам, переход на ключи, учёт ключей и проверку входов можно передать команде TakeIT. Это можно сделать в рамках обслуживания серверов, а обращения сотрудников по доступам принимает поддержка рабочих мест и пользователей.

Вывод

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