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

MAATRIX

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

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

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

Стоит отдельно понять, почему публичный ключ можно спокойно передавать, а приватный — нельзя показывать никому. Работает асимметричная криптография: то, что связано с одной частью пары, проверяется другой, но восстановить приватный ключ из публичного невозможно. Публичный ключ — как замочная скважина: её можно показывать всем, она бесполезна без самого ключа. Приватный ключ — сам ключ от замка, и он должен лежать только у вас. Отсюда правило гигиены: файл приватного ключа никогда не копируется на сервер и не отправляется в мессенджер. Если он всё же утёк, его нужно немедленно удалить из 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 намеренно игнорирует ключи, если к файлам слишком широкий доступ, — это защита от чужого вмешательства.

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

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

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

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

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

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

Теперь ужесточим настройки демона SSH. Откройте конфиг командой sudo nano /etc/ssh/sshd_config и выставьте три параметра:

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. Именно поэтому пароль пользователя стоит хранить в менеджере паролей даже после перехода на ключи: он остаётся вашим запасным входом через консоль. С рабочим ключом и знанием этого запасного пути вы управляете сервером спокойно и безопасно, не боясь ужесточать настройки.

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