SSH ключевая авторизация

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

Как работает SSH-ключевая авторизация

Процесс установки соединения (handshake) включает:

Клиент указывает, какой ключ хочет использовать (fingerprint публичного ключа)
Сервер проверяет наличие публичного ключа в authorized_keys
Сервер генерирует случайный challenge, шифрует его публичным ключом клиента
Клиент расшифровывает challenge приватным ключом, подписывает результат и отправляет обратно
Сервер верифицирует подпись и разрешает вход

Алгоритмы ключей (по убыванию рекомендуемости в 2024 году):

Ed25519 — эллиптическая криптография, ключ 256 бит, быстрая генерация, рекомендован OpenSSH начиная с версии 6.5 (2014)
ECDSA (P-256, P-384) — эллиптическая кривая, более короткий ключ, чем RSA
RSA — классика, минимум 2048 бит, рекомендуется 4096; всё ещё широко поддерживается
DSA — устарел, отключён в OpenSSH 7.0+

Генерация ключевой пары

# Ed25519 (рекомендуется):
ssh-keygen -t ed25519 -C "your_email@example.com"

# RSA 4096:
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Приватный ключ сохраняется в ~/.ssh/id_ed25519, публичный — в ~/.ssh/id_ed25519.pub. Публичный ключ добавляется на сервер командой ssh-copy-id user@server или вручную в ~/.ssh/authorized_keys.

История

Протокол SSH разработан Тату Илоненом в 1995 году как замена незащищённому Telnet. Ключевая авторизация вошла в SSH с самой первой версии протокола. OpenSSH — открытая реализация — появилась в 1999 году в составе OpenBSD и сегодня используется на >95% Linux-серверов. RFC 4252 (2006) стандартизировал метод public key authentication.

Безопасная настройка SSH

После настройки ключевой авторизации рекомендуется в /etc/ssh/sshd_config:

PasswordAuthentication no — отключить вход по паролю
PermitRootLogin no — запретить прямой вход под root
PubkeyAuthentication yes — явно включить ключевую авторизацию
AllowUsers username — ограничить список пользователей

Для дополнительной защиты используйте passphrase для шифрования приватного ключа (AES-256-CBC) — это защищает ключ при компрометации локальной машины. На VPS и выделенных серверах отключение парольной аутентификации в сочетании с fail2ban и nftables резко снижает поверхность атаки через SSH-брутфорс.

Типы ключей и их параметры

RSA — классический алгоритм. Рекомендованный размер ключа в 2024 году — 4096 бит (минимум 2048). Ed25519 — современная альтернатива на эллиптических кривых: ключ 256 бит обеспечивает безопасность эквивалентную RSA-3072, но генерируется за миллисекунды и подпись в 30 раз быстрее. Команда генерации: ssh-keygen -t ed25519 -C "user@host". ECDSA — промежуточный вариант, менее рекомендован из-за спорных вопросов к кривым NIST.

Хранение приватного ключа: файл ~/.ssh/id_ed25519 должен иметь права 600 (только владелец читает/пишет). Если права шире, SSH-клиент откажется использовать ключ. Публичный ключ (~/.ssh/id_ed25519.pub) добавляется в ~/.ssh/authorized_keys на сервере, права файла — 600, директории ~/.ssh — 700.

Hardening SSH через конфигурацию

После настройки ключевой авторизации рекомендуется отключить парольную аутентификацию в /etc/ssh/sshd_config:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password
AuthorizedKeysFile .ssh/authorized_keys

Дополнительно: MaxAuthTries 3 ограничивает попытки, LoginGraceTime 30 сокращает окно атаки, AllowUsers username ограничивает список пользователей. После изменений: systemctl reload sshd. Не закрывайте текущую сессию до проверки подключения в отдельном терминале — риск потерять доступ.

SSH-agent и forwarding

SSH-agent хранит расшифрованный приватный ключ в памяти процесса, избавляя от ввода парольной фразы при каждом подключении. ssh-add ~/.ssh/id_ed25519 добавляет ключ в агент. Agent forwarding (ssh -A) передаёт агент через SSH-туннель — полезно для работы через jump-серверы, но создаёт риск: компрометированный промежуточный сервер может использовать проброшенный агент.