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

MAATRIX

Пароль к серверу можно подобрать перебором, а хороший SSH-ключ — практически нет. Подключение по SSH-ключу на AlmaLinux 9 с нуля — базовая мера, с которой стоит начинать настройку любого сервера в семействе RHEL. Мы сгенерируем пару ключей на вашем компьютере, положим публичную часть на сервер и отключим вход по паролю, оставив только защищённый вход по ключу. Учтём и специфику AlmaLinux: служба SSH здесь называется sshd, а SELinux следит за правами на файлы ключей.

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

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

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

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

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

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

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

Чтобы не вводить парольную фразу при каждом подключении, используйте ssh-agent — фоновую программу, которая держит расшифрованный ключ в памяти на время сессии. Вы вводите фразу один раз при добавлении ключа командой ssh-add, а дальше агент сам подставляет его для всех подключений. Так вы получаете и защиту парольной фразой на случай кражи файла, и удобство входа без её постоянного ввода. На большинстве систем ssh-agent запускается автоматически при входе, и достаточно один раз выполнить ssh-add. Это разумный компромисс между безопасностью и повседневным удобством, который стоит освоить сразу, а не отказываться от парольной фразы ради экономии пары секунд.

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

Самый простой способ — утилита ssh-copy-id:

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

Команда попросит текущий пароль пользователя (последний раз) и запишет публичный ключ в файл ~/.ssh/authorized_keys на сервере. Файл authorized_keys — это обычный текстовый файл, где каждая строка — один разрешённый публичный ключ; хотите пустить второго администратора — дописываете ещё строку, хотите отозвать доступ — удаляете. В AlmaLinux с включённым SELinux есть важный нюанс прав: папка .ssh должна иметь права 700, а файл authorized_keys — 600, иначе SSH проигнорирует ключ. Если копировали файл вручную и SELinux пометил его неверным контекстом, поможет команда restorecon -R -v ~/.ssh, которая восстанавливает правильные метки.

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

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

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

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

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

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

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password

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

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

Перезапустите службу SSH. Важная деталь AlmaLinux: служба называется sshd, а не ssh, как в Debian:

sudo systemctl restart sshd

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

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

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

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