Ubuntu 24.04: подключение по SSH-ключу с нуля

MAATRIX

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

Как работает вход по ключу

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

Главное преимущество перед паролем в длине и стойкости. Пароль, который человек способен запомнить, перебирается словарём и брутфорсом, поэтому боты и ломятся в 22-й порт круглыми сутками. Ключ ed25519 математически невозможно подобрать перебором при нынешних вычислительных мощностях. Поэтому переход на ключи — это не «усложнение ради галочки», а качественно другой уровень защиты. Разберём по шагам.

Стоит отдельно понять, почему публичный ключ можно спокойно передавать, а приватный — нельзя показывать никому. Работает асимметричная криптография: то, что «зашифровано» одной частью пары, проверяется другой, но восстановить приватный ключ из публичного невозможно. Публичный ключ — как замочная скважина: её можно показывать всем, она бесполезна без самого ключа. Приватный ключ — это сам ключ от замка, и он должен лежать только у вас. Отсюда простое правило гигиены: файл id_ed25519 без расширения .pub никогда не копируется на сервер, не отправляется в мессенджер и не выкладывается в репозиторий. Если приватный ключ всё же утёк, его нужно немедленно удалить со всех серверов из authorized_keys и сгенерировать новую пару.

Генерируем пару ключей

Важно: ключ генерируется на вашем локальном компьютере (ноутбуке), а не на сервере. Откройте терминал у себя и выполните:

ssh-keygen -t ed25519 -C "ваш_комментарий"

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

Копируем публичный ключ на сервер

Самый простой способ — утилита ssh-copy-id, которая сама добавит ваш публичный ключ в нужный файл на сервере:

ssh-copy-id ваш_пользователь@ВАШ_IP

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

Проверяем вход по ключу

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

ssh ваш_пользователь@ВАШ_IP

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

Отключаем вход по паролю

Теперь ужесточим настройки демона SSH. Откройте конфиг:

sudo nano /etc/ssh/sshd_config

Найдите и выставьте три параметра: запретите вход по паролю, разрешите вход по ключу и запретите прямой вход root:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password

Значение prohibit-password для root означает, что администратор всё же сможет зайти по ключу (например, в аварийной ситуации), но не по паролю. Если root-вход вам не нужен вовсе, поставьте no. Сохраните файл. Эти три строки закрывают самый популярный вектор атаки на серверы — перебор паролей: даже правильно угаданное имя пользователя без ключа теперь бесполезно.

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

Применяем изменения безопасно

Перезапустите службу SSH, чтобы новые настройки вступили в силу:

sudo systemctl restart ssh

И вот здесь — важнейшая страховка. Не закрывая текущую сессию, откройте новое окно терминала и попробуйте зайти на сервер заново. Если вход по ключу работает, а по паролю сервер теперь отказывает, — настройка удалась. Если же что-то пошло не так, у вас остаётся открытая рабочая сессия, где можно откатить изменения в sshd_config. Такой приём с двумя окнами спасает от самой обидной ошибки новичка — потери доступа к собственному серверу из-за опечатки в конфиге.

Что делать при потере доступа

Если доступ всё же потерян — например, ключ удалён или конфиг сломан, — не паникуйте. В панели управления VPS есть веб-консоль (VNC или аналог), которая подключается к серверу напрямую, минуя SSH и сеть. Через неё вы войдёте по паролю пользователя, откроете sudo nano /etc/ssh/sshd_config и вернёте PasswordAuthentication yes либо заново добавите публичный ключ в authorized_keys. Поэтому, кстати, пароль пользователя стоит хранить в менеджере паролей даже после перехода на ключи: он остаётся вашим запасным входом через консоль. С рабочим ключом и знанием этого запасного пути вы управляете сервером спокойно и безопасно.

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