Вход по SSH-ключу и отключение парольной авторизации

1. Генерация ключа на своей машине

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

ssh-keygen -t ed25519 -a 100 -C "workstation-2026" -f ~/.ssh/sputnik

Что означают параметры: -t ed25519 — современный алгоритм, короткие ключи и быстрая проверка; -a 100 — сто раундов KDF, замедляет перебор парольной фразы, если файл ключа украдут; -f — отдельный файл, чтобы не смешивать с ключами других проектов.

Парольную фразу задавайте обязательно. Без неё украденный файл ключа даёт мгновенный доступ ко всем вашим серверам. Чтобы не вводить её при каждом подключении, используйте ssh-agent.

В Windows команда работает в PowerShell и в Git Bash одинаково — OpenSSH встроен в систему начиная с Windows 10.

2. Копирование ключа на сервер

Если у вас Linux или macOS, достаточно одной команды:

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

В Windows утилиты ssh-copy-id нет, поэтому делаем вручную:

type $env:USERPROFILE\.ssh\sputnik.pub | ssh root@ВАШ_IP "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Проверяем права — sshd игнорирует файлы с избыточным доступом и молча отказывает:

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

3. Проверка до того, как что-то ломать

Откройте второе окно терминала и подключитесь ключом, не закрывая первое:

ssh -i ~/.ssh/sputnik root@ВАШ_IP

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

journalctl -u ssh -n 50 --no-pager

4. Отключение входа по паролю

Правим конфигурацию демона:

nano /etc/ssh/sshd_config

Приводим три параметра к такому виду (найдите существующие строки, а не дописывайте вторые — сработает первая):

PermitRootLogin prohibit-password
PasswordAuthentication no
KbdInteractiveAuthentication no

На Ubuntu 22.04 и новее проверьте каталог с дополнительными файлами: /etc/ssh/sshd_config.d/. Облачные образы часто кладут туда файл, который переопределяет основной конфиг и включает пароль обратно.

Проверяем синтаксис и применяем:

sshd -t && systemctl reload ssh

Команда reload не разрывает открытые сессии — если что-то пойдёт не так, ваше первое окно останется живым.

5. Отдельный пользователь вместо root

Работать под root постоянно — привычка, которая однажды дорого обходится. Заводим пользователя с sudo:

adduser deploy
usermod -aG sudo deploy
rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy

После проверки входа под deploy можно запретить root полностью, заменив в конфиге PermitRootLogin prohibit-password на no.

6. Смена порта: нужно ли

Перенос SSH с 22 на нестандартный порт не добавляет стойкости — современные сканеры проходят весь диапазон за минуты. Но он резко сокращает объём мусора в логах: количество попыток падает примерно в сорок раз, и в журнале становится видно реальные события.

Port 2222

Не забудьте разрешить новый порт в файрволе до перезапуска sshd — см. инструкцию по nftables.

7. Если доступ всё-таки потерян

Это не катастрофа: в панели управления есть VNC-консоль, которая работает независимо от sshd и файрвола. Войдите в консоль, авторизуйтесь по паролю root из письма и верните PasswordAuthentication yes либо добавьте правильный ключ.

Если забыт и пароль root — загрузитесь в режиме восстановления через netboot.xyz (переключается в панели), смонтируйте корневой раздел и смените пароль через chroot. Данные при этом не теряются.

Короткий чек-лист

• Ключ ed25519 создан на своей машине, с парольной фразой.
• Публичная часть лежит в ~/.ssh/authorized_keys на сервере, права 600.
• Вход ключом проверен во втором окне до правки конфига.
• PasswordAuthentication no, каталог sshd_config.d проверен.
• Конфиг проверен через sshd -t, применён через reload.
• Вы знаете, где в панели находится VNC-консоль.