tanaka.host  / блог
RSSЗаказать VPS
Введение/Безопасность

Вход по SSH-ключу и запрет входа по паролю

Создаём ключ ed25519, кладём его на сервер, проверяем и отключаем пароль и root так, чтобы cloud-init не вернул всё обратно. Ubuntu, Debian, AlmaLinux.

6 ноября 2026 г.·3 мин чтения·ssh, ubuntu, debian, almalinux

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

План:

  1. Создать отдельного пользователя вместо root.
  2. Создать ключ на своём компьютере.
  3. Положить публичную часть на сервер.
  4. Проверить вход по ключу в новом окне.
  5. Только после этого отключить пароль и root.

Понадобится доступ под root по паролю — IP и пароль из кабинета.

1. Отдельный пользователь

Ubuntu и Debian:

adduser admin
usermod -aG sudo admin

AlmaLinux, Rocky, CentOS, Oracle Linux:

adduser admin
passwd admin
usermod -aG wheel admin

adduser спросит пароль и несколько необязательных полей — их пропускаем клавишей Enter. Пароль понадобится для sudo.

2. Ключ на вашем компьютере

Команда одна и та же в Терминале macOS и Linux и в PowerShell на Windows:

ssh-keygen -t ed25519 -a 64 -C "my-laptop"

ssh-keygen создал пару ключей и показал отпечаток

  • Куда сохранить — Enter, путь по умолчанию ~/.ssh/id_ed25519.
  • Passphrase — лучше задать. Это пароль на сам файл ключа: если ноутбук украдут, сервер не достанется вместе с ним. Агент SSH (встроен в macOS и Windows) запомнит passphrase на время сессии.

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

Если id_ed25519.pub уже есть, ключ у вас уже создан — используйте его, не перезаписывайте.

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

3. Публичный ключ на сервер

macOS и Linux:

ssh-copy-id admin@IP_СЕРВЕРА

Windows (PowerShell), потому что ssh-copy-id там нет:

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh admin@IP_СЕРВЕРА "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Пароль пользователя admin спросят в последний раз.

Если вы уже вошли на сервер под root и ключ root’а хотите отдать новому пользователю, вместо копирования с компьютера можно сделать на сервере:

rsync --archive --chown=admin:admin ~/.ssh /home/admin

4. Проверка в новом окне

Текущее окно с сессией не закрывайте. В новом:

ssh admin@IP_СЕРВЕРА
sudo whoami

Пароль от сервера спрашиваться не должен — максимум passphrase от ключа. sudo whoami выводит root. Если что-то не так, разбираемся до следующего шага: ssh -v admin@IP_СЕРВЕРА покажет, какие ключи пробовал клиент и почему сервер их отверг.

5. Отключаем пароль и root

На Ubuntu и Debian конфигурация SSH читается не только из /etc/ssh/sshd_config, а ещё из файлов в /etc/ssh/sshd_config.d/, причём первое встреченное значение побеждает, а Include стоит в самом начале основного файла. Во многих облачных образах лежит 50-cloud-init.conf с PasswordAuthentication yes, и правка основного файла ничего не меняет. Посмотрите, что уже задано:

grep -ri passwordauthentication /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

Поэтому создаём свой файл с префиксом 00, который прочитается раньше остальных:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

Если хотите оставить вход под root, но только по ключу — PermitRootLogin prohibit-password.

Сохраните (Ctrl+O, Enter, Ctrl+X) и проверьте, что получилось:

sudo sshd -t
sudo sshd -T | grep -Ei "permitrootlogin|passwordauthentication"

sshd -t молчит, sshd -T подтверждает: root и пароль отключены

Первая команда молчит, если конфиг корректен. Вторая должна показать permitrootlogin no и passwordauthentication no. Если показывает другое — перебивает другой файл, смотрите ls /etc/ssh/sshd_config.d/.

Перезапустите SSH:

sudo systemctl restart ssh      # Ubuntu, Debian
sudo systemctl restart sshd     # AlmaLinux, Rocky, CentOS

6. Финальная проверка

Ещё одно новое окно:

ssh admin@IP_СЕРВЕРА                                  # пускает
ssh root@IP_СЕРВЕРА                                   # Permission denied
ssh -o PubkeyAuthentication=no admin@IP_СЕРВЕРА       # Permission denied (publickey)

Третья команда подтверждает, что без ключа на сервер не попасть.

Если потеряли доступ

Откройте консоль сервера в кабинете tanaka.host — это прямое подключение к экрану виртуальной машины, SSH для него не нужен. Войдите под root с паролем из кабинета и удалите файл /etc/ssh/sshd_config.d/00-hardening.conf, затем systemctl restart ssh.

Несколько серверов и ключей

Опишите серверы в ~/.ssh/config на своём компьютере:

Host web
    HostName 203.0.113.10
    User admin
    IdentityFile ~/.ssh/id_ed25519

После этого ssh web — и вы на сервере. Следующий шаг — брандмауэр и fail2ban.