SSH-ключи вместо пароля на VPS: как настроить и отключить вход по паролю

Коротко

SSH-ключ — это пара файлов: закрытый остаётся у вас, открытый уходит на сервер. Вход по ключу защищён лучше пароля, потому что его почти невозможно подобрать перебором. Создайте ключ командой ssh-keygen -t ed25519, скопируйте открытую часть на VPS через ssh-copy-id, проверьте вход и только после этого отключите вход по паролю директивой PasswordAuthentication no.

Порядок важен. Если отключить пароль, не проверив ключ, вы можете потерять доступ к серверу.

Зачем нужны ключи

Пароль root из письма — слабое место. Его можно подбирать автоматически, и боты делают это круглосуточно. Ключ устроен иначе: сервер проверяет подпись, которую может создать только владелец закрытого ключа. Подобрать такую подпись перебором практически невозможно.

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

Шаг 1. Создаём ключ на своём компьютере

На компьютере с Linux или macOS выполните:

ssh-keygen -t ed25519 -C "ноутбук"

Тип ed25519 — современный и короткий, его поддерживают все актуальные версии OpenSSH. Флаг -C добавляет комментарий, по которому потом удобно понять, с какого устройства ключ. Программа спросит путь для сохранения. Оставьте путь по умолчанию ~/.ssh/id_ed25519. Затем задайте парольную фразу. Она защищает закрытый ключ, если его кто-то получит. Пустую фразу ставить не стоит, если ноутбук не зашифрован.

В результате появятся два файла:

• ~/.ssh/id_ed25519 — закрытый ключ. Его не отправляйте никому и никуда не загружайте.
• ~/.ssh/id_ed25519.pub — открытый ключ. Его можно передавать и класть на сервер.

В Windows 10 и 11 команда та же, выполняется в PowerShell. Файлы окажутся в C:\Users\<имя>\.ssh\. Парольную фразу лучше задать и там.

Шаг 2. Копируем открытый ключ на VPS

Самый простой способ — команда ssh-copy-id:

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

Она попросит пароль root один раз и добавит открытый ключ в файл ~/.ssh/authorized_keys на сервере, создав каталог ~/.ssh с закрытыми правами, если его нет. В Windows команды ssh-copy-id нет, там ключ копируют так (в PowerShell):

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh root@203.0.113.10 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Теперь проверьте вход:

ssh root@203.0.113.10

Если пароль больше не спрашивают, ключ работает. Если спросили, значит, ключ не подхватился: проверьте, что вы копировали именно .pub, а не закрытый файл.

Шаг 3. Отключаем вход по паролю

Только после успешного входа по ключу откройте настройки SSH на сервере. Главное правило sshd: если директива встречается несколько раз, действует первое найденное значение. В Ubuntu 24.04 основной /etc/ssh/sshd_config подключает файлы из /etc/ssh/sshd_config.d/ в самом начале, и читаются они по алфавиту.

На новом VPS EGN при создании системы записывается файл /etc/ssh/sshd_config.d/00-egn-access.conf с двумя строками: PasswordAuthentication yes и PermitRootLogin yes. Именно благодаря ему вы смогли войти по паролю из письма. Из-за порядка чтения новый файл с другим именем, например 00-egn-keys.conf, окажется после него и ничего не изменит. Поэтому сначала посмотрите, где что задано:

sudo grep -ri -E "PasswordAuthentication|PermitRootLogin" /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

Если в списке есть 00-egn-access.conf, правьте его:

sudo nano /etc/ssh/sshd_config.d/00-egn-access.conf

Приведите содержимое к такому виду:

PasswordAuthentication no
PermitRootLogin prohibit-password

Вторая строка разрешает root вход только по ключу. Если вы завели отдельного пользователя с sudo, можно поставить PermitRootLogin no, но делайте это, только когда вход под ним проверен. Если файла 00-egn-access.conf нет (например, вы переустановили систему или образ другой), создайте файл /etc/ssh/sshd_config.d/00-keys.conf с теми же строками.

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

sudo sshd -t && sudo systemctl reload ssh

Команда sshd -t проверяет конфигурацию без применения. Если ошибок нет, она молча завершится, и тогда reload перечитает настройки. Если ошибка есть, reload не выполнится, а текущая сессия останется рабочей.

Проверить итоговое значение можно так:

sudo sshd -T | grep -i passwordauthentication

Должно вывести passwordauthentication no.

Проверьте вход в новом окне до перезагрузки

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

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

У одного пользователя может быть несколько ключей: для ноутбука, для рабочего компьютера и для сервера автоматической выкладки. Каждый открытый ключ — это отдельная строка в ~/.ssh/authorized_keys. Удалить доступ конкретного устройства можно, удалив его строку.

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

ssh-keygen -t ed25519 -C "deploy-script" -f ~/.ssh/deploy_ed25519

Частые ошибки

Permission denied (publickey). Сервер не принимает ключ. Причины: ключ не добавлен в authorized_keys, неверные права на каталог ~/.ssh или файл authorized_keys, либо ключ от другого компьютера. Права должны быть такими: каталог 700, файл 600.

Пароль отключили, а ключ не работает. Именно поэтому порядок такой: сначала проверьте ключ, потом отключайте пароль. Если всё же застряли, откройте в карточке услуги вкладку «Консоль» (VNC): вход на консоли идёт мимо sshd, поэтому логин root и пароль из письма там продолжают работать. Исправьте настройки и вернитесь в SSH.

Закрытый ключ попал в репозиторий или чат. Если это случилось, немедленно удалите открытый ключ из authorized_keys на всех серверах, создайте новый и выпустите его заново. Закрытый ключ, который попал на публичный ресурс, считается скомпрометированным.

Ключи с правами 644 на файле закрытого ключа. OpenSSH откажется его использовать и покажет предупреждение о слишком открытых правах. Выставьте chmod 600 ~/.ssh/id_ed25519.

Таблица: симптом, причина и решение

Порядок файлов стоит запомнить отдельно. Облачные образы Ubuntu иногда содержат собственный 50-cloud-init.conf с PasswordAuthentication, а EGN добавляет 00-egn-access.conf. Если вы правите только основной sshd_config, изменение не сработает: sshd берёт первое найденное значение, а файлы из sshd_config.d читаются раньше. Поэтому проверка через sshd -T и grep по обоим местам обязательна.

Альтернатива: скопировать ключ вручную

Если ssh-copy-id не установлен, одна команда с перенаправлением делает то же самое:

cat ~/.ssh/id_ed25519.pub | ssh root@203.0.113.10 'mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys'

Команда добавит строку в конец файла, поэтому не запускайте её дважды для одного ключа: строки будут дублироваться. Дубликат безвреден, но неаккуратен.

Пример: несколько серверов в одном конфиге

Для удобства заведите алиасы в ~/.ssh/config, как в статье про первый вход. Ключ можно указать явно, если на компьютере несколько ключей:

Host egn-vps
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host deploy-bot
    HostName 203.0.113.20
    User deploy
    IdentityFile ~/.ssh/deploy_ed25519
    IdentitiesOnly yes

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

Как проверить, что пароль действительно отключён

Настройка без проверки — это предположение. Проверьте её с другого компьютера или из сессии, в которой нет вашего ключа. Команда ниже просит сервер войти только по паролю и отключает ключи на стороне клиента:

ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password root@203.0.113.10

Правильный ответ — отказ без запроса пароля, примерно такой:

root@203.0.113.10: Permission denied (publickey).

Если вы видите запрос пароля, настройка не применилась: проверьте файлы в /etc/ssh/sshd_config.d/ и выполните sudo sshd -T | grep -i passwordauthentication. Пока значение не no, не считайте защиту включённой.

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

Пример: ключ для сайта и ключ для себя

Представьте, что на VPS живут сайт и Telegram-бот. Вам нужен доступ себе, а боту — только для выкладки. Разумно завести два отдельных ключа и два отдельных пользователя на сервере: например, admin с sudo и deploy без sudo, который может только перезапускать свой сервис. Тогда ключ бота, если он утечёт, не даст права на всю систему.

Создать ключ для бота можно так:

ssh-keygen -t ed25519 -C "bot-deploy" -f ~/.ssh/bot_ed25519 -N ""

Флаг -N "" задаёт пустую парольную фразу. Для автоматической выкладки это обычная практика, но ключ нужно хранить на машине, которой вы доверяете, и ограничить права пользователя на сервере.

Вопросы и ответы

Нужен ли пароль к ключу?

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

Что выбрать: ed25519 или RSA?

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

Можно ли вернуть вход по паролю?

Да. Верните PasswordAuthentication yes в том же файле, где вы его меняли, и выполните sudo sshd -t && sudo systemctl reload ssh. Но лучше оставить вход по ключам: пароль root в любом случае остаётся рабочим на VNC-консоли в кабинете.

Итог

Ключ ed25519 — лучший способ входа на VPS: он надёжнее пароля и удобнее для автоматизации. Создайте ключ, скопируйте открытую часть через ssh-copy-id, проверьте вход и только потом отключите PasswordAuthentication. Дальше переходите к защите сервера: Базовая защита VPS: ufw, fail2ban и обновления. Основы входа описаны в статье VPS: первые шаги и вход по SSH.

Сервер под VPS за пару минут — egnetwork.ru