Как настроить SSH-ключи на Ubuntu и не потерять доступ

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

Эта инструкция предполагает, что на сервере уже есть отдельный пользователь с правом выполнять административные команды через sudo. Его создание и назначение групп разобраны в материале о пользователях и sudo.

Как устроен вход по SSH-ключу

SSH-ключ состоит из двух связанных частей. Закрытая часть хранится на компьютере владельца и подтверждает его право на вход. Открытая часть записывается на сервер и используется для проверки. По открытому ключу нельзя восстановить закрытый за практически достижимое время.

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

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

Подготовьте путь возврата

До любых изменений откройте консоль VPS в панели провайдера и оставьте действующее SSH-соединение открытым. Консоль — запасной вход, а открытая сессия позволит вернуть конфигурацию, если новое подключение не сработает.

Запишите имя пользователя, которым будете входить. В примерах это admin, а учебный IP-адрес 203.0.113.10 нужно заменить адресом своего VPS. Пользователь admin должен уже существовать и иметь собственный домашний каталог.

Не отключайте пароль и не запрещайте root, пока не завершён отдельный тест нового пользователя. Успешное выполнение команды настройки ещё не доказывает, что SSH примет ключ извне.

Создайте отдельный ключ на своём компьютере

Сначала проверьте каталог .ssh на своём компьютере: возможно, для этого сервера уже создан отдельный ключ. Не перезаписывайте существующий файл, если не знаете, где он используется.

Чтобы создать новую пару Ed25519, выполните команду локально в PowerShell, Terminal или другом терминале с установленным OpenSSH:

ssh-keygen -t ed25519 -C "admin vps"

ssh-keygen создаёт пару ключей. Параметр -t ed25519 выбирает современный тип ключа, а -C добавляет понятную подпись к открытой части. Программа спросит, куда сохранить результат. Укажите новый файл, например vps_admin_ed25519, в предложенном каталоге .ssh, а затем введите парольную фразу дважды.

В результате появятся два файла. vps_admin_ed25519 — закрытый ключ: его нельзя отправлять на сервер или другому человеку. vps_admin_ed25519.pub — открытый ключ, который нужно добавить пользователю admin на VPS.

Добавьте открытый ключ пользователю на VPS

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

ssh-copy-id -i ~/.ssh/vps_admin_ed25519.pub admin@203.0.113.10

Параметр -i указывает открытый файл с расширением .pub. Команда не должна копировать закрытый файл без расширения. После сообщения о добавленном ключе старый парольный вход пока остаётся доступным.

В стандартном PowerShell ssh-copy-id может отсутствовать. Тогда скопируйте одну строку из файла .pub и войдите на VPS прежним способом. Если каталог ключей ещё не создан, подготовьте его и откройте файл разрешённых ключей:

sudo install -d -o admin -g admin -m 700 /home/admin/.ssh
sudoedit /home/admin/.ssh/authorized_keys

Первая команда создаёт каталог .ssh и сразу назначает правильного владельца и права. В редакторе добавьте открытую часть ключа одной строкой и сохраните файл. Один открытый ключ должен занимать одну строку; перенос внутри неё повредит запись.

После ручного добавления закрепите владельца и права:

sudo chown -R admin:admin /home/admin/.ssh
sudo chmod 700 /home/admin/.ssh
sudo chmod 600 /home/admin/.ssh/authorized_keys

Первая команда назначает пользователя admin владельцем каталога и его содержимого. Две следующие запрещают другим пользователям изменять каталог .ssh и файл разрешённых ключей. SSH проверяет эти права и может отказаться использовать небезопасный файл.

Проверьте ключ в новом окне терминала

Не закрывая прежнее соединение, откройте второе окно терминала на своём компьютере. Явно укажите только что созданный закрытый ключ:

ssh -i ~/.ssh/vps_admin_ed25519 admin@203.0.113.10

Параметр -i сообщает SSH, какой закрытый ключ использовать. После ввода его парольной фразы должно появиться приглашение командной строки VPS. Команда whoami, выполненная уже на сервере, должна вывести admin.

Затем выполните на VPS sudo -v. Система запросит пароль пользователя и при успехе вернёт приглашение без сообщения об ошибке. Эта проверка подтверждает, что новый пользователь сможет администрировать сервер после запрета прямого входа root.

Если вход не состоялся, ничего не ограничивайте. В старой сессии проверьте написание пользователя, наличие одной целой строки в authorized_keys и владельца файлов. Сообщение сервера за последние минуты можно посмотреть командой sudo journalctl -u ssh --since "10 minutes ago".

Запретите вход по паролю и прямой вход root

Серверную часть SSH обслуживает программа sshd. Её основной файл настроек может подключать дополнительные файлы из каталога /etc/ssh/sshd_config.d/. Отдельный локальный файл проще найти, проверить и убрать при откате, чем правку среди стандартных комментариев.

Откройте новый файл на VPS безопасным системным редактором:

sudoedit /etc/ssh/sshd_config.d/00-local-access.conf

sudoedit создаёт временную пользовательскую копию, запускает настроенный текстовый редактор и после сохранения переносит результат с административными правами. Добавьте пять строк, заменив admin своим проверенным именем пользователя:

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
AllowUsers admin

Первая строка разрешает ключи. Следующие две отключают обычный пароль и интерактивные запросы, через которые некоторые настройки также принимают пароль. PermitRootLogin no запрещает прямой вход как root. AllowUsers admin ограничивает SSH перечисленными пользователями; если доступ нужен нескольким людям или автоматизации, их имена должны быть указаны в этой же строке через пробел.

Не копируйте AllowUsers admin, если ваш проверенный пользователь называется иначе. Ошибка в этом имени заблокирует новый вход даже с правильным ключом.

Проверьте и примените конфигурацию

Сначала попросите SSH проверить синтаксис и показать итоговые значения. Эти команды выполняются на VPS из всё ещё открытой старой сессии:

sudo sshd -t
sudo sshd -T | grep -E '^(pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|permitrootlogin|allowusers) '

Первая команда при правильном файле не выводит ничего. Если показана ошибка и номер строки, исправьте её до продолжения. Вторая команда печатает настройки, которые сервер применит с учётом всех подключённых файлов. В выводе должны быть pubkeyauthentication yes, три ожидаемых запрета и правильное имя после allowusers.

Теперь перечитайте конфигурацию без остановки уже открытых соединений:

sudo systemctl reload ssh
sudo systemctl status ssh --no-pager

reload применяет настройки службы SSH и сохраняет действующие сессии. В выводе второй команды ищите состояние active (running) и отсутствие ошибки загрузки конфигурации.

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

Как вернуть доступ при ошибке

Если новая сессия не открывается, используйте старую, которая всё ещё работает. Переименуйте локальный файл настроек, проверьте синтаксис и снова перечитайте конфигурацию:

sudo mv /etc/ssh/sshd_config.d/00-local-access.conf /etc/ssh/sshd_config.d/00-local-access.conf.disabled
sudo sshd -t
sudo systemctl reload ssh

Файл с окончанием .disabled больше не считается конфигурацией SSH. После возврата старого поведения разберите причину: неверное имя в AllowUsers, повреждённый открытый ключ, права файлов или конфликт с другим файлом настроек.

Если все сетевые сессии закрыты, войдите через консоль провайдера и выполните те же действия. Не переустанавливайте VPS до проверки этой возможности.

Что делать после защиты SSH

Теперь сервер принимает административный вход по отдельному ключу, а root и пароли недоступны через SSH. Это защищает только способ входа. Следующие независимые задачи — разрешить в сетевом фильтре лишь нужные порты и настроить реакцию на повторяющиеся попытки подключения.

В маршруте «VPS с нуля» следующим идёт понятный порядок проверки сети. Расширенный маршрут защиты отдельно разбирает правила UFW и nftables, а затем Fail2Ban по реальному журналу SSH. Для каждого администратора храните отдельный открытый ключ и удаляйте его сразу после прекращения доступа.

Первоисточники

• Ubuntu Server: OpenSSH
• OpenBSD: руководство ssh-keygen
• OpenBSD: параметры sshd_config
• systemd: управление службами через systemctl