Вход по паролю — самое слабое место нового сервера: через несколько минут после запуска к порту SSH начинают подбирать пароли боты. Вход по ключу перебором не взломать, а набирать пароль больше не придётся. Ниже — весь путь: создать ключ, положить его на сервер, проверить и только потом закрыть вход по паролю.
Настройки сервера проверены на Ubuntu 24.04, Ubuntu 26.04 и Debian 12. Вместо 203.0.113.10 подставьте адрес своего сервера, вместо root — своего пользователя.
Как это работает
Ключ — это пара файлов. Закрытый ключ остаётся на вашем компьютере, его никому не передают. Открытый ключ (файл с окончанием .pub) кладут на сервер в ~/.ssh/authorized_keys. При подключении сервер проверяет, что у вас есть закрытый ключ к этому открытому, — сам ключ по сети не передаётся.
Шаг 1. Создать ключ
В Windows 10 и 11 клиент OpenSSH уже встроен — команды те же, их вводят в PowerShell. В macOS и Linux — в терминале:
ssh-keygen -t ed25519 -C "laptop-ivan"
-t ed25519— современный тип ключа: короткий и надёжный. Старые системы, которые его не понимают, сегодня почти не встречаются.-C— подпись, чтобы потом понять, чей это ключ. Удобно писать имя компьютера.
Программа спросит, куда сохранить ключ — нажмите Enter, чтобы оставить путь по умолчанию (~/.ssh/id_ed25519, в Windows — C:\Users\<имя>\.ssh\id_ed25519). Затем предложит парольную фразу: она шифрует закрытый ключ на диске, и если ноутбук украдут, ключом не воспользуются. Её стоит задать.
Шаг 2. Положить открытый ключ на сервер
macOS и Linux
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@203.0.113.10
Команда один раз попросит пароль от сервера и сама допишет ключ в ~/.ssh/authorized_keys.
Windows
В Windows нет ssh-copy-id, поэтому делаем то же самое одной командой в PowerShell:
type $env:USERPROFILE\.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"
Вручную
Если удобнее руками: откройте id_ed25519.pub на своём компьютере, скопируйте одну строку целиком (начинается с ssh-ed25519) и на сервере выполните:
mkdir -p ~/.ssh && chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys # вставьте строку, сохраните: Ctrl+O, Enter, Ctrl+X
chmod 600 ~/.ssh/authorized_keys
Шаг 3. Проверить вход по ключу
ssh root@203.0.113.10
Если пароль от сервера больше не спрашивают (может спросить парольную фразу ключа — это нормально), всё готово. Если спрашивают пароль сервера — ключ не подхватился, смотрите раздел «Если не пускает».
Шаг 4. Короткое имя для подключения
Чтобы не набирать адрес, порт и путь к ключу, добавьте в файл ~/.ssh/config на своём компьютере (в Windows — C:\Users\<имя>\.ssh\config):
Host myserver
HostName 203.0.113.10
User root
IdentityFile ~/.ssh/id_ed25519
Теперь достаточно ssh myserver. Если позже смените порт SSH, допишите строку Port <номер>.
Шаг 5. Отключить вход по паролю
Делайте это, только убедившись на шаге 3, что вход по ключу работает, и не закрывайте текущее подключение до конца проверки — если что-то пойдёт не так, через него можно всё вернуть.
На сервере создайте отдельный файл настроек:
sudo tee /etc/ssh/sshd_config.d/00-keys-only.conf > /dev/null <<'EOF'
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
EOF
Почему отдельный файл с префиксом 00: SSH берёт первое найденное значение каждой настройки, а файлы из sshd_config.d читает по алфавиту. В облачных образах часто есть 50-cloud-init.conf со строкой PasswordAuthentication yes — наш файл прочитается раньше и победит. PermitRootLogin prohibit-password оставляет пользователю root вход только по ключу.
Проверьте настройки и примените их:
sudo sshd -t # нет вывода — ошибок нет
sudo sshd -T | grep -E 'passwordauthentication|kbdinteractive|permitrootlogin'
sudo systemctl reload ssh # в AlmaLinux и CentOS служба называется sshd
sshd -T должен показать passwordauthentication no и kbdinteractiveauthentication no. Для root в Ubuntu 24.04 и Debian 12 он пишет permitrootlogin without-password — это старое имя того же значения prohibit-password. Теперь в новом окне терминала подключитесь ещё раз — по ключу должно пускать. А попытка войти с паролем должна заканчиваться отказом:
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password root@203.0.113.10
# root@203.0.113.10: Permission denied (publickey).
Если не пускает
Запустите подключение с подробным выводом — он почти всегда показывает причину:
ssh -v root@203.0.113.10
Частые причины:
| Что видно | В чём дело и что делать |
|---|---|
Permission denied (publickey) сразу после настройки |
Ключ не в том файле или не у того пользователя. Проверьте ~/.ssh/authorized_keys именно у пользователя, под которым входите |
| Ключ на месте, но сервер его игнорирует | Слишком открытые права. Нужно: chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys, домашний каталог не должен быть доступен на запись другим |
В выводе -v нет строки Offering public key |
Клиент не нашёл ключ: укажите его явно — ssh -i ~/.ssh/id_ed25519 … или пропишите IdentityFile в ~/.ssh/config |
| Отключили пароль, а ключ не работает | Войдите через веб-консоль сервера в панели хостинга, удалите /etc/ssh/sshd_config.d/00-keys-only.conf и выполните sudo systemctl reload ssh |
Что дальше
- Ключ для каждого компьютера свой: так при потере ноутбука достаточно удалить одну строку из
authorized_keys. - Закрытый ключ не пересылайте в мессенджерах и не храните в облачных папках без шифрования.
- Следующий шаг защиты — файрвол и автоматическая блокировка подбора паролей: первая настройка сервера на Ubuntu.
- Отдельный ключ с ограниченными правами для автоматического деплоя — в статье о деплое из GitHub Actions.