Вход по SSH-ключу в Linux: настройка ключей ed25519 и отключение входа по паролю

Любой сервер с публичным IPv4 через несколько минут после запуска начинают атаковать боты, перебирающие SSH-пароли. В этой инструкции показано, как настроить вход по SSH-ключу в Linux с современным ключом ed25519, а затем отключить вход по паролю SSH и не потерять доступ к серверу. Шаги подходят для Debian 11/12, Ubuntu 20.04/22.04/24.04, CentOS 7 и Rocky Linux / AlmaLinux 8 и 9 — на облачных серверах JUSTG в Йоханнесбурге, Москве, Токио и Сеуле, а также на выделенных серверах.

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

Ключ создаётся на том компьютере, с которого вы подключаетесь, а не на сервере. Ключи ed25519 короткие, быстрые и поддерживаются всеми актуальными версиями OpenSSH. Парольная фраза защитит закрытый ключ при утере ноутбука, а ssh-agent избавит от её повторного ввода.

# On your own computer (Linux, macOS, or Windows 10/11 PowerShell)
ssh-keygen -t ed25519 -C "laptop-2026"
# Press Enter to accept ~/.ssh/id_ed25519, then set a passphrase

Появятся два файла: id_ed25519 (закрытый ключ, никому не передавайте) и id_ed25519.pub (открытый ключ, его копируют на серверы).

Шаг 2: Скопируйте открытый ключ на сервер

В Linux и macOS проще всего использовать ssh-copy-id: утилита в последний раз войдёт по паролю и добавит ключ в ~/.ssh/authorized_keys на сервере.

ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]
# Custom port example:
ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 2222 [email protected]

В Windows ssh-copy-id нет, но ключ можно передать по конвейеру из PowerShell:

# Windows PowerShell (ssh-copy-id is not included on Windows)
type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh [email protected] "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Шаг 3: Добавьте ключ вручную и исправьте права на authorized_keys

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

# On the server, as the user that will log in
mkdir -p ~/.ssh
nano ~/.ssh/authorized_keys      # paste ONE key per line, then save
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R "$(id -un)":"$(id -gn)" ~/.ssh
# CentOS / Rocky / AlmaLinux with SELinux enforcing:
restorecon -Rv ~/.ssh

Шаг 4: Проверьте вход по SSH-ключу до изменения настроек

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

ssh -i ~/.ssh/id_ed25519 -o PasswordAuthentication=no [email protected]

Шаг 5: Отключите вход по паролю SSH в sshd_config

Современные дистрибутивы подключают /etc/ssh/sshd_config.d/*.conf строкой Include в начале основного файла, а sshd использует первое прочитанное значение каждого параметра. Поэтому файл вроде 50-cloud-init.conf с PasswordAuthentication yes может незаметно перекрыть вашу правку ниже в sshd_config. Drop-in-файл с именем, которое стоит первым по алфавиту, решает проблему.

# Check that the drop-in directory is included
grep -i '^Include' /etc/ssh/sshd_config

# Create a drop-in that sorts first (sshd keeps the FIRST value it reads)
cat > /etc/ssh/sshd_config.d/01-key-only.conf <<'EOF'
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
EOF

# Look for files that still turn passwords back on (e.g. 50-cloud-init.conf)
grep -ri 'PasswordAuthentication' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

В CentOS 7 и других старых системах без каталога sshd_config.d впишите эти четыре строки прямо в /etc/ssh/sshd_config и закомментируйте более ранний PasswordAuthentication yes. PermitRootLogin prohibit-password оставляет вход root только по ключу; если вы входите обычным пользователем с sudo, укажите no.

Шаг 6: Проверьте конфигурацию SSH и перезагрузите службу

# Validate syntax first - no output means OK
sshd -t
# Show the effective values
sshd -T | grep -Ei 'passwordauthentication|pubkeyauthentication|permitrootlogin|kbdinteractive'

# Debian / Ubuntu
systemctl reload ssh
# CentOS / Rocky / AlmaLinux
systemctl reload sshd

reload не обрывает текущую сессию, но это только половина проверки.

Шаг 7: Проверьте вход во второй сессии, не закрывая первую

# From a NEW terminal on your computer
ssh [email protected]
# Must be refused:
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password [email protected]
# Expected: Permission denied (publickey).

Если что-то пошло не так, исправьте drop-in-файл в открытой первой сессии и снова выполните reload. Если доступ уже потерян, войдите в личный кабинет JUSTG → Мои продукты и услуги → выберите VPS → панель управления и откройте VNC-консоль; если не нашли её, создайте тикет.

Частые вопросы

ed25519 лучше RSA для SSH-ключей?

Для новых ключей — да. ed25519 даёт высокую стойкость при гораздо более коротком ключе и более быстром рукопожатии. RSA 4096 нужен только для очень старых систем без поддержки ed25519.

Почему сервер всё ещё спрашивает пароль?

Выполните sshd -T | grep -i passwordauthentication. Если выводится yes, другой файл в sshd_config.d читается раньше вашего. Также проверьте /var/log/auth.log (Debian/Ubuntu) или /var/log/secure (Rocky/AlmaLinux) на сообщения «bad ownership or modes» для ~/.ssh.

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

Да, скопируйте один и тот же открытый ключ на каждый сервер через ssh-copy-id. Закрытый ключ храните только на своих устройствах, а ключ утерянного устройства отзывайте, удаляя его строку из authorized_keys.

Если войти по SSH-ключу так и не удалось, создайте тикет по адресу https://www.justg.com/submitticket.php — техническая поддержка JUSTG поможет.