SSH-ключи вместо пароля на Ubuntu 24.04: пошаговая установка

MAATRIX

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

Почему ключ надёжнее пароля

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

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

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

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

Шаг 1. Генерируем ключ на своём компьютере

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

ssh-keygen -t ed25519 -C "you@example"

Программа предложит путь для сохранения (по умолчанию ~/.ssh/id_ed25519) и попросит парольную фразу. Не пропускайте её: парольная фраза шифрует закрытый ключ на диске, и если ноутбук украдут, ключом всё равно не воспользуются без неё. В результате появятся два файла: закрытый id_ed25519 и открытый id_ed25519.pub. Наружу, на сервер, уходит только открытый — файл с расширением .pub.

Шаг 2. Загружаем открытый ключ на сервер

Самый простой способ перенести открытый ключ на сервер — утилита ssh-copy-id. Она сама добавит его в нужный файл на сервере с правильными правами. Пока парольный вход ещё включён, выполните с локальной машины:

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@ВАШ_IP

Команда попросит текущий пароль сервера — это последний раз, когда он понадобится. Если ssh-copy-id недоступен, ключ можно добавить вручную: содержимое .pub-файла дописывается отдельной строкой в ~/.ssh/authorized_keys на сервере. Важно проследить за правами: папка .ssh должна быть доступна только владельцу, иначе SSH из соображений безопасности проигнорирует ключ:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

У MAATRIX сервер можно получить сразу с вашим SSH-ключом при заказе, а оплатить из России картой, по СБП, криптой или токеном MAAT — тогда шаг ручной загрузки не понадобится вовсе.

Шаг 3. Проверяем вход по ключу

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

ssh root@ВАШ_IP

Если вместо запроса пароля сервер пустил вас сразу (или спросил парольную фразу ключа, а не пароль сервера) — ключ настроен верно. Этот шаг критичен: пока вы не убедились, что вход по ключу стабилен, ни в коем случае не отключайте парольную аутентификацию. Держите рабочую сессию открытой как страховку на случай, если что-то пойдёт не так, — это спасает от истории «сам себя запер».

Шаг 4. Отключаем вход по паролю

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

nano /etc/ssh/sshd_config

Установите следующие значения:

PasswordAuthentication no
PermitRootLogin prohibit-password
KbdInteractiveAuthentication no

Первая строка отключает пароль полностью, вторая разрешает root заходить только по ключу, третья закрывает интерактивные способы ввода пароля. Затем перезапустите демон и снова проверьте вход из нового окна, не закрывая страховочную сессию:

systemctl restart ssh

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

Шаг 5. Настраиваем удобство и несколько машин

Чтобы не указывать адрес и ключ каждый раз, опишите сервер в локальном файле ~/.ssh/config на своём компьютере. Тогда подключение сведётся к короткому псевдониму:

Host myserver
    HostName ВАШ_IP
    User root
    IdentityFile ~/.ssh/id_ed25519

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

Шаг 6. Резервный доступ и обслуживание

У перехода на ключи есть один риск, о котором стоит сказать честно: если вы потеряете закрытый ключ и не оставите запасного пути, попасть на сервер будет нечем. Поэтому продумайте резервный доступ заранее. Держите бэкап ключа в надёжном месте (например, в менеджере паролей) и убедитесь, что у провайдера есть аварийный вход. У MAATRIX доступ к серверу есть и через панель управления с веб-консолью, так что даже при утере ключа вы сможете зайти и добавить новый.

В остальном ключи не требуют ухода. Раз в какое-то время просматривайте authorized_keys и убирайте строки устройств, которыми больше не пользуетесь. Если ключ мог скомпрометироваться, сгенерируйте новый и замените старый на всех серверах. Такой минимальный порядок держит доступ к серверу и надёжным, и удобным на годы вперёд.

Частые вопросы