SSH-ключи вместо пароля: настройка за 5 минут

SSH-ключи — первое, что стоит настроить на новом сервере. Вход по ключу SSH надёжнее любого пароля: 256-битный ключ ed25519 невозможно подобрать перебором, а боты, которые круглосуточно стучатся на порт 22 любого публичного IP, останутся ни с чем. Вся настройка укладывается в три действия: сгенерировать пару ключей, скопировать публичную часть на сервер и отключить парольную аутентификацию. В этой инструкции — рабочие команды для сервера на Ubuntu 24.04 LTS и клиентов на Windows, macOS и Linux. Если вы ещё ни разу не подключались к серверу, начните со статьи как подключиться к VPS по SSH, а затем возвращайтесь сюда.

Почему вход по ключу SSH надёжнее пароля

SSH-ключи — это пара из двух файлов. Приватный ключ (id_ed25519) остаётся только на вашем компьютере. Публичный (id_ed25519.pub) кладётся на сервер в файл ~/.ssh/authorized_keys. При подключении сервер отправляет клиенту случайный запрос, клиент подписывает его приватным ключом, сервер проверяет подпись публичным. Секрет по сети не передаётся вообще — перехватывать нечего.

Практические преимущества перед паролем:

• Перебор бесполезен. Пароль из 10 символов боты подбирают по словарям; ключ ed25519 — это 256 бит энтропии, брутфорс исключён физически.
• Нечему утекать. Пароль можно подсмотреть, выудить фишингом или перехватить кейлоггером. Приватный ключ никогда не покидает ваш диск.
• Быстрее в работе. Один раз настроили — и заходите на сервер без ввода пароля.
• Автоматизация. rsync, scp, git, деплой-скрипты и CI работают по ключу без интерактивных запросов.

Единственная зона ответственности — сам файл приватного ключа: его нужно защитить passphrase и не копировать куда попало. Об этом ниже.

Ed25519 или RSA: какой ключ генерировать

Современный стандарт — Ed25519. RSA имеет смысл только для подключения к старому оборудованию, которое не понимает новых алгоритмов.

Ubuntu 24.04, свежие Debian, AlmaLinux и Rocky Linux, а также встроенные SSH-клиенты Windows 10/11 и macOS поддерживают ed25519 из коробки. Дальше в статье используем именно его.

Шаг 1. Генерируем пару ключей

Команда одинаковая для Windows (PowerShell), macOS и Linux — OpenSSH встроен во все три системы:

ssh-keygen -t ed25519 -C "work-laptop"

Флаг -t ed25519 задаёт тип ключа, -C — комментарий-метку, по которой вы потом отличите этот ключ от других в authorized_keys (удобно писать имя устройства или почту).

Программа задаст два вопроса:

1. Куда сохранить ключ. Нажмите Enter — подойдёт путь по умолчанию: ~/.ssh/id_ed25519 в Linux/macOS или C:\Users\имя\.ssh\id_ed25519 в Windows.
2. Passphrase. Пароль, которым шифруется приватный ключ на диске. Рекомендую задать: если файл украдут, без passphrase он бесполезен. Вводить её каждый раз не придётся — это решает ssh-agent (шаг 4).

На выходе два файла: id_ed25519 — приватный, никому и никогда не передаётся; id_ed25519.pub — публичный, его и будем копировать на сервер.

Если нужен RSA для совместимости со старым устройством, команда такая: ssh-keygen -t rsa -b 4096 -C "work-laptop".

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

macOS и Linux: ssh-copy-id

Самый короткий путь — утилита ssh-copy-id, которая сама добавит ключ в authorized_keys и выставит права:

ssh-copy-id user@IP

Введите пароль от сервера в последний раз — дальше он не понадобится. Если SSH висит на нестандартном порту: ssh-copy-id -p 2222 user@IP.

Windows: одна команда в PowerShell

В Windows ssh-copy-id нет, но его заменяет конвейер:

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

Команда читает публичный ключ, передаёт его по SSH и дописывает в authorized_keys на сервере, создав каталог ~/.ssh, если его ещё нет.

Ручной способ и права доступа

Если оба варианта недоступны, скопируйте содержимое .pub-файла в буфер и на сервере выполните:

mkdir -p ~/.ssh
echo "ssh-ed25519 AAAAC3NzaC1lZDI1... work-laptop" >> ~/.ssh/authorized_keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Права — критичный момент: если каталог ~/.ssh или файл authorized_keys доступны на запись кому-то кроме владельца, sshd молча проигнорирует ключ, и вы будете гадать, почему сервер по-прежнему просит пароль. chmod 700 и chmod 600 решают это.

Теперь проверьте вход, не закрывая текущую сессию: откройте новое окно терминала и выполните ssh user@IP. Сервер должен пустить вас без пароля (спросит только passphrase от ключа, если вы её задали).

На VPS от Cheap-Host всё это можно проделать через минуту после заказа: сервер разворачивается за 45–60 секунд, IP и доступ по SSH выдаются сразу — ключ логично закинуть первым же действием, вместе с остальными пунктами из чек-листа первых шагов после покупки VPS.

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

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

В Ubuntu 24.04 есть нюанс, о который спотыкаются даже опытные администраторы. Главный конфиг /etc/ssh/sshd_config первой же строкой подключает drop-in каталог: Include /etc/ssh/sshd_config.d/*.conf. На облачных образах там обычно лежит файл 50-cloud-init.conf со строкой PasswordAuthentication yes — и по правилам sshd выигрывает первое встреченное значение параметра, а не последнее. То есть правка одного лишь sshd_config ничего не даст.

Сначала посмотрите, где параметр задан сейчас:

grep -ri "PasswordAuthentication" /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

Надёжное решение — свой drop-in файл с именем, которое сортируется раньше 50-cloud-init.conf:

printf "PasswordAuthentication no\nKbdInteractiveAuthentication no\n" | sudo tee /etc/ssh/sshd_config.d/00-no-password.conf

Файл 00-no-password.conf прочитается первым, и его значения станут окончательными. Вторая строка отключает клавиатурно-интерактивную аутентификацию — ещё один канал, через который может пролезть запрос пароля.

Проверьте конфигурацию на синтаксические ошибки:

sudo sshd -t

Пустой вывод означает, что всё в порядке. Применяем:

sudo systemctl restart ssh

Убедиться, что пароль действительно отключён, можно попыткой входа с принудительно выключенным ключом:

ssh -o PubkeyAuthentication=no user@IP

Ответ Permission denied (publickey) — то, что нужно: парольная дверь заколочена.

Боты при этом никуда не денутся — они продолжат стучаться и засорять логи. Снизить шум помогают fail2ban и файрвол UFW: первый банит настойчивые IP, второй закрывает всё лишнее.

Шаг 4. Passphrase и ssh-agent: удобство без потери защиты

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

Linux:

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

macOS умеет запоминать passphrase в системной связке ключей:

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

В Windows ssh-agent — это служба, которую нужно один раз включить (PowerShell от администратора):

Get-Service ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agent
ssh-add $env:USERPROFILE\.ssh\id_ed25519

После этого passphrase вводится один раз, а все последующие подключения проходят мгновенно.

Ещё два практических совета. Во-первых, заведите резервный ключ со второго устройства (например, с телефона через Termux или с домашнего ПК) и добавьте его в authorized_keys — если основной ноутбук выйдет из строя, доступ к серверу останется. Во-вторых, для нескольких серверов не копируйте приватный ключ между машинами: публичный ключ можно класть на сколько угодно серверов, а на каждом клиентском устройстве держите свою пару.

FAQ

Что делать, если я потерял приватный ключ?

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

Можно ли использовать один ключ для нескольких серверов?

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

Обязательна ли passphrase для ключа?

Технически нет, практически — очень желательна. Без passphrase любой, кто получит файл id_ed25519 (украденный ноутбук, скомпрометированный бэкап), сразу получает доступ ко всем вашим серверам. С passphrase файл бесполезен без пароля, а ssh-agent избавляет от необходимости вводить её постоянно.

Почему сервер просит пароль даже после PasswordAuthentication no?

Три типовые причины. Первая — в Ubuntu 24.04 параметр переопределён drop-in файлом /etc/ssh/sshd_config.d/50-cloud-init.conf: найдите все вхождения командой grep -ri "PasswordAuthentication" /etc/ssh/sshd_config /etc/ssh/sshd_config.d/ и задайте no в файле, который читается первым. Вторая — вы забыли перезапустить службу: sudo systemctl restart ssh. Третья — сервер отверг ключ из-за прав доступа: проверьте chmod 700 ~/.ssh и chmod 600 ~/.ssh/authorized_keys.

Вывод

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

Если сервера для практики ещё нет — у Cheap-Host есть тариф Start за 450 ₽/мес: 6 vCPU, 8 ГБ RAM, 96 ГБ NVMe, KVM с полным root-доступом и безлимитным трафиком. Сервер разворачивается за 45–60 секунд, так что от оплаты до первого входа по ключу пройдёт меньше времени, чем заняло чтение этой статьи.