Debian/Ubuntu: безопасная настройка SSH-ключей на VDS

SSH — первая дверь в ваш VDS. Через неё вы обновляете систему, деплоите сайт, чините базу, перезапускаете nginx, смотрите логи и иногда спасаете проект ночью. Поэтому настройка SSH на Debian/Ubuntu — не косметика, а базовая эксплуатационная гигиена.

В этой инструкции я покажу аккуратный сценарий: сначала создаём нормального пользователя с sudo, добавляем SSH-ключ, проверяем вход в отдельной сессии, и только потом включаем PasswordAuthentication no, PubkeyAuthentication yes и ограничиваем PermitRootLogin. Главная идея — безопасно перейти на предсказуемую конфигурацию без риска запереть себя снаружи.

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

Что мы хотим получить в итоге

Для обычного VDS на Debian или Ubuntu разумная базовая цель выглядит так: вход по SSH-ключу разрешён, вход по паролю выключен, прямой вход root запрещён или сильно ограничен, административные действия выполняются через sudo, а конфигурация проверяется перед перезагрузкой сервиса. Это закрывает самый частый класс проблем: перебор паролей, слабые root-пароли, забытые временные доступы и хаотичные настройки в /etc/ssh/sshd_config.

Важно понимать границы: SSH-ключи не заменяют обновления системы, firewall, мониторинг входов и резервные копии. Но без ключевой аутентификации остальные меры часто оказываются надстройкой над слабым фундаментом. Если парольный вход включён, атакующему достаточно найти пару «логин-пароль». Если включён только ключевой вход, атакующему уже нужен приватный ключ, а при passphrase — ещё и парольная фраза к нему.

В статье предполагаю, что у вас есть root-доступ или пользователь с sudo, сервер работает на Debian/Ubuntu, а SSH доступен на стандартном или уже изменённом порту. Команды применимы к Debian 12 и Ubuntu 22.04/24.04; на более новых версиях логика та же, но отдельные параметры OpenSSH стоит сверять через man sshd_config.

Подготовка: проверьте текущий доступ и откройте вторую сессию

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

ssh root@203.0.113.10

Проверьте версию OpenSSH и имя сервиса. На Debian/Ubuntu серверный сервис обычно называется ssh, а не sshd.

ssh -V
systemctl status ssh

Если вы работаете не под root, проверьте sudo:

sudo -v
sudo whoami

Команда должна вернуть root. Если sudo не настроен, сначала решите этот вопрос, иначе после отключения root-входа вы можете получить пользователя, который умеет входить на сервер, но не может им управлять.

Создаём отдельного администратора вместо постоянной работы под root

На многих VDS первый доступ выдаётся под root. Это удобно для первичной настройки, но плохо для повседневной эксплуатации. Root не оставляет пространства для разделения прав: любая ошибка в команде сразу выполняется с максимальными полномочиями. Лучше создать отдельного пользователя, выдать ему sudo и дальше подключаться именно под ним.

adduser deploy
usermod -aG sudo deploy

На Debian пакет sudo может быть не установлен в минимальном образе. Проверьте и при необходимости установите его:

apt update
apt install sudo

Проверить группы пользователя можно так:

id deploy

В выводе должна быть группа sudo. После этого не спешите запрещать root: сначала настроим ключи и протестируем вход.

Генерируем SSH-ключ на рабочей машине

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

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

ssh-keygen -t ed25519 -a 100 -C admin-workstation

Когда ssh-keygen спросит путь, можно оставить стандартный ~/.ssh/id_ed25519 или указать отдельный файл, например ~/.ssh/fastfox_vds_ed25519. Если вы ведёте несколько проектов, отдельные ключи на проект или контур сильно упрощают отзыв доступа.

Passphrase лучше задавать. Да, это дополнительный ввод, но его можно удобно кешировать через ssh-agent. Зато украденный файл приватного ключа без passphrase сразу становится готовым доступом.

eval $(ssh-agent -s)
ssh-add ~/.ssh/id_ed25519

Публичная часть обычно лежит рядом и заканчивается на .pub:

cat ~/.ssh/id_ed25519.pub

Эту строку мы добавим пользователю deploy на сервере.

Добавляем публичный ключ на VDS

Самый простой способ — ssh-copy-id. Он создаст каталог ~/.ssh, добавит ключ в authorized_keys и выставит права. Выполняется команда с вашей локальной машины, не на сервере:

ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@203.0.113.10

Если ssh-copy-id недоступен, сделайте вручную. На сервере под root:

install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
nano /home/deploy/.ssh/authorized_keys
chown deploy:deploy /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys

В файл /home/deploy/.ssh/authorized_keys вставьте одну строку публичного ключа целиком. Не переносите её вручную на несколько строк. У типичного Ed25519-ключа строка начинается с ssh-ed25519, дальше идёт длинный набор символов, а в конце комментарий.

Права критичны. OpenSSH специально отказывается использовать ключи, если домашний каталог, .ssh или authorized_keys доступны на запись слишком широкому кругу пользователей. Это одна из самых частых причин ошибки Permission denied (publickey).

ls -ld /home/deploy /home/deploy/.ssh
ls -l /home/deploy/.ssh/authorized_keys

Нормальная картина: домашний каталог не должен быть доступен на запись группе и всем, .ssh имеет права 700, authorized_keys — 600, владелец — deploy.

Проверяем вход по ключу до изменения sshd_config

Теперь с локальной машины пробуем войти под новым пользователем. Текущую root-сессию не закрываем.

ssh -i ~/.ssh/id_ed25519 deploy@203.0.113.10

Если вы указали нестандартный порт, добавьте -p:

ssh -i ~/.ssh/id_ed25519 -p 2222 deploy@203.0.113.10

После входа проверьте sudo:

sudo whoami

Если команда возвращает root, база готова. Если вход не работает, не трогайте PasswordAuthentication и PermitRootLogin. Сначала разберите причину. Для подробной диагностики используйте verbose-режим клиента:

ssh -vvv -i ~/.ssh/id_ed25519 deploy@203.0.113.10

На сервере полезно смотреть журнал SSH:

journalctl -u ssh -n 100 --no-pager

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

Облачный VDS-сервер

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия Нидерланды

Смотреть тарифы

Настраиваем sshd_config.d: ключи да, пароли нет

В Debian/Ubuntu лучше не редактировать большой /etc/ssh/sshd_config без необходимости. Современные пакеты OpenSSH подключают фрагменты из /etc/ssh/sshd_config.d/. Так проще видеть локальные изменения, переносить их между серверами и откатывать.

Создадим отдельный файл:

sudo nano /etc/ssh/sshd_config.d/99-local-hardening.conf

Базовый безопасный вариант:

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
AuthenticationMethods publickey
MaxAuthTries 3
LoginGraceTime 30
X11Forwarding no

PubkeyAuthentication yes явно разрешает вход по ключам. Обычно он и так включён по умолчанию, но явная настройка полезна для читаемости и аудита. PasswordAuthentication no отключает классический парольный вход. KbdInteractiveAuthentication no закрывает интерактивный парольный механизм, который в старых инструкциях часто называли через ChallengeResponseAuthentication. На современных Debian/Ubuntu ориентируйтесь именно на KbdInteractiveAuthentication.

PermitRootLogin no запрещает прямой вход root по SSH. Это самый спокойный вариант, если у вас уже есть пользователь с sudo. Альтернатива PermitRootLogin prohibit-password разрешает root только по ключу и запрещает пароль. Такой режим иногда используют на этапе первичной автоматизации, но для постоянной эксплуатации я предпочитаю no: меньше исключений, проще объяснить команде.

AuthenticationMethods publickey дополнительно фиксирует, что для входа подходит только public key. Это не обязательная строка для базовой настройки, но она помогает избежать сюрпризов, если в системе есть PAM-модули или старые параметры, которые могут вернуть интерактивный вход. MaxAuthTries 3 уменьшает число попыток в рамках одного соединения, а LoginGraceTime 30 ограничивает время на прохождение аутентификации.

Не меняйте сразу порт SSH, способ входа и firewall одним коммитом. Сначала добейтесь стабильного входа по ключу, затем отдельно занимайтесь сетевыми ограничениями.

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

Перед применением обязательно выполните синтаксическую проверку. Это команда номер один, которая спасает от случайной опечатки в удалённом доступе.

sudo sshd -t

Если команда ничего не вывела и завершилась с кодом 0, синтаксис корректен. Можно применить конфигурацию без разрыва текущих соединений:

sudo systemctl reload ssh

Если reload не поддержан в вашем окружении, используйте restart, но только при открытой резервной сессии:

sudo systemctl restart ssh

Теперь посмотрите итоговые значения, которые видит сам sshd. Это важнее, чем глазами читать несколько конфигов: порядок включений, Match-блоки и дубли параметров могут запутать.

sudo sshd -T | grep -E 'pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|permitrootlogin|authenticationmethods|maxauthtries|logingracetime'

В выводе должны быть строки вроде:

pubkeyauthentication yes
passwordauthentication no
kbdinteractiveauthentication no
permitrootlogin no
authenticationmethods publickey

После этого откройте новое окно терминала и проверьте вход. Именно новое: активная сессия не доказывает, что новые подключения работают.

ssh -i ~/.ssh/id_ed25519 deploy@203.0.113.10

Если вход успешен и sudo работает, можно считать переход на SSH-ключи выполненным.

Ограничиваем пользователей через AllowUsers или группу

На небольшом VDS обычно нет смысла разрешать SSH всем системным пользователям. Если на сервере есть www-data, технические пользователи приложений, пользователи баз или сервисные аккаунты, им не нужен интерактивный SSH-доступ.

Самый простой вариант — AllowUsers:

AllowUsers deploy

Если администраторов несколько, перечислите их через пробел:

AllowUsers deploy vasya admin2

Для команды удобнее группа:

sudo groupadd ssh-admins
sudo usermod -aG ssh-admins deploy

И в конфигурации:

AllowGroups ssh-admins

После изменения групп пользователь должен перелогиниться, чтобы новая группа появилась в его сессии. Не забывайте снова проверять конфиг через sshd -t и применять reload.

Клиентский ~/.ssh/config: меньше ошибок в повседневной работе

Когда серверов становится больше одного, длинные команды с -i, -p и IP-адресами превращаются в источник ошибок. На рабочей машине заведите клиентский конфиг:

Host production-vds
    HostName 203.0.113.10
    User deploy
    Port 22
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes
    ServerAliveInterval 30
    ServerAliveCountMax 3

Теперь подключение выглядит проще:

ssh production-vds

IdentitiesOnly yes особенно полезен, если в агенте много ключей. Без него клиент может предложить серверу несколько неподходящих ключей подряд, упереться в MaxAuthTries и получить отказ до того, как дойдёт до правильного ключа.

Что делать с root: no или prohibit-password

Параметр PermitRootLogin часто вызывает споры. Для VDS, где вы администрируете всё вручную или через Ansible, оптимальный постоянный режим — PermitRootLogin no. Вы входите под обычным пользователем, а привилегии повышаете через sudo. Это даёт журналирование команд, возможность быстро отозвать доступ конкретному человеку и меньше риск случайного разрушительного действия.

PermitRootLogin prohibit-password имеет смысл как временный компромисс: например, когда провайдер выдал только root-доступ, вы ещё не настроили пользователя, но уже хотите отключить пароль root. В таком режиме root сможет войти по ключу, но не по паролю. После создания sudo-пользователя лучше перейти на no.

Не используйте PermitRootLogin yes как норму. Даже с сильным ключом это создаёт лишнюю привычку работать от root. А если где-то временно включили пароль и забыли — получите типичную поверхность для автоматического перебора.

Нужно ли менять порт SSH

Смена порта с 22 на другой уменьшает шум в логах, но не является полноценной защитой. Сканеры быстро находят открытые порты, а реальная безопасность всё равно держится на ключах, отключённых паролях, ограничении пользователей, firewall и обновлениях. Поэтому я не советую начинать hardening со смены порта.

Если всё же меняете порт, делайте это отдельным шагом после успешной настройки ключей. Сначала разрешите новый порт в firewall или панели управления VDS, затем поменяйте Port в SSH, проверьте sshd -t, примените reload и только потом тестируйте новое подключение.

Port 2222

Проверка с клиента:

ssh -p 2222 deploy@203.0.113.10

Если используете облачный firewall, security group или nftables/ufw на сервере, доступ должен быть разрешён на всех уровнях. Частая ошибка: порт в sshd_config изменили, а firewall оставили на старом 22. Если на сервере есть контейнеры и правила Docker, пригодится отдельный разбор про Docker, iptables и nftables на VDS.

Ротация и отзыв SSH-ключей

SSH-ключи нужно рассматривать как доступы, а не как «один раз настроил и забыл». Если сотрудник ушёл из проекта, ноутбук потерян, ключ попал в резервную копию без шифрования или использовался в небезопасном окружении CI, ключ следует отозвать.

Отзыв прост: удалите соответствующую строку из authorized_keys. Именно поэтому комментарии в ключах важны. Вместо безымянного id_ed25519 лучше иметь понятный хвост: vasya-laptop-2026, ci-deploy-prod, admin-yubikey.

sudo nano /home/deploy/.ssh/authorized_keys

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

who
w
ss -tnp | grep sshd

Для нескольких администраторов не складывайте все ключи в один общий аккаунт без учёта. Минимально приемлемый вариант — отдельный пользователь на человека или хотя бы понятные комментарии в authorized_keys. Лучший вариант для растущей инфраструктуры — централизованное управление доступами, но для одного VDS аккуратный authorized_keys уже сильно лучше хаоса.

Типовые ошибки после PasswordAuthentication no

Ошибка Permission denied (publickey)

Это значит, что сервер не принял ни один предложенный ключ. Начинайте с клиента: указан ли правильный IdentityFile, не мешает ли агент, совпадает ли пользователь. Затем проверьте сервер: есть ли ключ в authorized_keys, правильный ли владелец, не сломаны ли права.

sudo namei -l /home/deploy/.ssh/authorized_keys
sudo tail -n 100 /var/log/auth.log

На Ubuntu и Debian события SSH обычно попадают в /var/log/auth.log и journald. В минимальных образах rsyslog может быть не установлен, тогда ориентируйтесь на journalctl.

Клиент предлагает не тот ключ

Если в ssh-agent много ключей, сервер может отклонить соединение раньше, чем клиент предложит нужный. Используйте IdentitiesOnly yes в клиентском конфиге или явно указывайте ключ:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 deploy@203.0.113.10

После изменения порта SSH недоступен

Проверьте три слоя: слушает ли sshd новый порт, разрешён ли он локальным firewall, открыт ли он во внешнем firewall провайдера или панели управления. На сервере:

sudo ss -ltnp | grep ssh
sudo systemctl status ssh
sudo journalctl -u ssh -n 50 --no-pager

Если доступа уже нет, используйте консоль восстановления провайдера. Именно поэтому смену порта и отключение паролей лучше не совмещать в один шаг.

Мини-чеклист безопасного применения

1. Открыта резервная SSH-сессия под root или sudo-пользователем.
2. Создан отдельный пользователь, проверена группа sudo.
3. Публичный ключ добавлен в authorized_keys, права на .ssh и файл корректны.
4. Новый вход по ключу протестирован в отдельном терминале.
5. Включены PubkeyAuthentication yes, PasswordAuthentication no, KbdInteractiveAuthentication no.
6. PermitRootLogin установлен в no после проверки sudo-доступа.
7. Конфигурация проверена через sshd -t, применена через systemctl reload ssh.
8. Итоговые параметры сверены через sshd -T.
9. Новый вход после reload проверен, старая сессия закрыта только после успеха.

Итог

Безопасная настройка SSH на Debian/Ubuntu для VDS — это не одна магическая строка PasswordAuthentication no. Надёжный путь состоит из последовательности: подготовить sudo-пользователя, добавить ключ, проверить права, протестировать вход, только потом отключать пароли и root-доступ. Такой порядок чуть длиннее, зато он почти исключает классическую аварию «усилил безопасность и потерял доступ к серверу».

Если вы настраиваете новый сервер, внесите этот сценарий в bootstrap-чеклист рядом с обновлениями, firewall, резервными копиями и мониторингом. Через полгода вы поблагодарите себя: доступы будут понятными, отзыв ключей — быстрым, а логи SSH — заметно спокойнее.