Есть вещи, которые любой Linux-инженер начинает делать автоматически спустя пару лет работы:

  • проверять df -h

  • ругаться на SELinux

  • ненавидеть legacy Java

  • и первым делом отключать вход по паролю через SSH

Потому что парольная авторизация на сервере в 2026 году - это примерно как оставить root/root на production базе данных и надеяться на силу молитвы.

Особенно весело это выглядит, когда сервер торчит в интернет. Через пару минут после открытия 22/tcp в логах уже начинается:

  • Китай

  • боты

  • brute force

  • "admin/admin"

  • "test/test"

  • и тысячи попыток подобрать пароль

Поэтому нормальная инфраструктура давно использует SSH-ключи.

Это:

  • безопаснее

  • удобнее

  • быстрее

  • отлично автоматизируется

  • идеально подходит для Ansible, CI/CD и Kubernetes-инфраструктуры

Сегодня разберем:

  • что такое SSH ключи

  • как они работают

  • как создать ключ

  • как подключиться к серверу

  • как отключить парольную авторизацию

  • как правильно организовать доступ в production

И самое главное - разберем все с практической стороны, а не в стиле:

"нажмите далее и все заработает"

Потому что в инфраструктуре "все заработает" обычно заканчивается потерей доступа к серверу в 3 часа ночи.

Что такое SSH ключи

SSH-ключи работают по принципу:

  • публичный ключ

  • приватный ключ

Это криптографическая пара.

Публичный ключ

Можно:

  • копировать

  • отправлять

  • хранить на сервере

Обычно лежит в файле:

id_ed25519.pub

Приватный ключ

Это самое важное.

Его:

  • нельзя никому отдавать

  • нельзя хранить в Git

  • нельзя отправлять в чатик

  • нельзя копировать на чужие машины

Обычно файл выглядит так:

id_ed25519

Если злоумышленник получил приватный ключ - считайте, получил ваш доступ.

Почему SSH ключи лучше паролей

1. Намного безопаснее

Хороший SSH-ключ практически невозможно подобрать brute force.

Пароль: P@ssw0rd123  сломают быстро.

Ключ Ed25519: нет.

2. Удобно автоматизировать

Ansible, Terraform, Jenkins, GitLab CI, Kubernetes-ноды - все это прекрасно работает через SSH-ключи.

Без:

  • интерактивного ввода

  • паролей

  • боли

  • страданий

3. Можно полностью отключить парольный вход

А вот это уже огромный плюс.

Даже если:

  • знают логин

  • знают IP

  • знают пользователя

без ключа подключиться не смогут.

Какие ключи использовать

В 2026 году нормальный выбор:

Ed25519

Не RSA 1024.
Не древние DSA.
Не "что было в старом мануале 2012 года".

Именно Ed25519.

Он:

  • быстрее

  • безопаснее

  • компактнее

  • поддерживается почти везде

Генерация SSH ключа

На Linux или macOS:

ssh-keygen -t ed25519 -C "admin@example.com"

На Windows:

  • через PowerShell

  • Git Bash

  • WSL

  • Windows Terminal

работает точно так же.

Что спросит ssh-keygen

Куда сохранить ключ

Обычно оставляем:

~/.ssh/id_ed25519

Passphrase

Это пароль на сам ключ.

Очень желательно ставить.

Да, это чуть менее удобно.
Но если ноутбук украдут - ключ без passphrase использовать не смогут.

Что получится

После генерации появятся:

~/.ssh/id_ed25519
~/.ssh/id_ed25519.pub

Копируем ключ на сервер

Самый удобный способ:

ssh-copy-id user@server

Например:

ssh-copy-id admin@10.10.10.5

Команда:

  • создаст .ssh

  • положит ключ

  • выставит права

Очень удобно.

Если ssh-copy-id нет

Тогда руками.

Создаем директорию:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
Добавляем ключ:
cat id_ed25519.pub >> ~/.ssh/authorized_keys

Выставляем права:

chmod 600 ~/.ssh/authorized_keys

Подключение по SSH ключу

Теперь можно подключаться:

ssh user@server

Если ключ нестандартный:

ssh -i ~/.ssh/mykey user@server

Проверяем что работает

Смотрим:

ssh -v user@server

В выводе должно быть:

Offering public key
Authentication succeeded

Отключаем парольную авторизацию

Вот теперь начинается настоящий production.

Редактируем:

/etc/ssh/sshd_config

Меняем:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

Что означают параметры

PasswordAuthentication no

Запрещает вход по паролю.

PubkeyAuthentication yes

Разрешает SSH-ключи.

PermitRootLogin no

Запрещает вход под root. И это правильно.

Перезапускаем SSH

Ubuntu/Debian:

systemctl restart ssh

RHEL/AlmaLinux/Rocky:

systemctl restart sshd

ОЧЕНЬ ВАЖНО

Никогда не закрывайте текущую SSH-сессию пока не проверили новую.

Сначала:

  • открыть второе окно

  • проверить вход по ключу

  • убедиться что все работает

И только потом отключать пароль.

Иначе можно случайно:

  • заблокировать себе доступ

  • ехать в датацентр

  • вспоминать где лежит IPMI

  • и принимать жизненные решения

SSH agent

Чтобы не вводить passphrase каждый раз:

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

Теперь ключ хранится в памяти.

Очень удобно.

Конфиг SSH клиента

Создаем:

~/.ssh/config

Пример:

Host prod
    HostName 10.10.10.10
    User admin
    IdentityFile ~/.ssh/id_ed25519

Host k8s-master
    HostName 10.10.10.20
    User ubuntu
    IdentityFile ~/.ssh/id_ed25519

Теперь можно писать:

ssh prod

Вместо:

ssh -i ~/.ssh/id_ed25519 admin@10.10.10.10

SSH ключи и Ansible

Ansible вообще обожает SSH-ключи.

Inventory:

[k8s]
10.10.10.10
10.10.10.11

[k8s:vars]
ansible_user=ubuntu
ansible_ssh_private_key_file=~/.ssh/id_ed25519

И дальше:

ansible all -m ping

Без:

  • паролей

  • ручного ввода

  • страданий

Что НЕ нужно делать

Не храните приватные ключи в Git

Никогда.

Вообще.

Даже:

  • "это тестовый"

  • "это временно"

  • "репозиторий приватный"

Нет.

Не используйте один ключ на всех

Это огромая ошибка.

У каждого инженера:

  • свой ключ

  • свой доступ

  • своя история действий

Не отключайте все способы входа сразу

Сначала:

  • проверка

  • тест

  • резервный доступ

  • console/IPMI

Потом отключение паролей.

Что используют в больших инфраструктурах

Обычно:

  • SSH CA

  • HashiCorp Vault

  • Teleport

  • SSO

  • короткоживущие сертификаты

  • bastion host

  • WireGuard/VPN

Но основа всего этого - обычные SSH ключи.

Итог

SSH-ключи - это базовая гигиена любой Linux-инфраструктуры.

Они:

  • безопаснее паролей

  • удобнее в автоматизации

  • отлично работают с DevOps-инструментами

  • уменьшают риск взлома сервера

И если у вас до сих пор включен SSH по паролю на production-серверах, то лучше исправить это раньше, чем очередной бот из интернета решит потренироваться именно на вашем VPS.