Ответ
В DevOps-практике мы используем несколько методов аутентификации SSH, выбирая их в зависимости от требований безопасности и автоматизации:
-
Аутентификация по публичному ключу (Public Key Authentication) — это стандарт де-факто. Приватный ключ хранится у клиента, а публичный — в
~/.ssh/authorized_keysна сервере. Я настраиваю это для всех серверов и сервисных аккаунтов CI/CD.# Генерация пары ключей (предпочитаю Ed25519) ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_ci -C "ci-server" # Копирование публичного ключа на хост ssh-copy-id -i ~/.ssh/id_ed25519_ci.pub deploy@production-host -
Аутентификация через SSH-агент (Agent Forwarding) — позволяет безопасно использовать локальные ключи для доступа к промежуточным хостам. Я применяю это при работе с бастион-хостами.
eval $(ssh-agent) ssh-add ~/.ssh/id_ed25519 ssh -A bastion-host # Ключ будет передан дальше -
Аутентификация на основе сертификатов (Certificate-Based) — более масштабируемое решение для больших инфраструктур. Центральный CA (например, HashiCorp Vault) подписывает сертификаты пользователей или хостов с коротким временем жизни.
# Подписание ключа через Vault vault write ssh/sign/my-role public_key=@$HOME/.ssh/id_ed25519.pub -
Двухфакторная аутентификация (2FA) — комбинация ключа и одноразового кода (TOTP). Я настраивал это через
pam_google_authenticatorдля критически важных окружений, чтобы добавить дополнительный уровень защиты. -
Парольная аутентификация — в продакшене я всегда отключаю её в
sshd_config(PasswordAuthentication no), так как она уязвима к брутфорс-атакам.
Для автоматизации в пайплайнах CI/CD я использую либо заранее развернутые ключи, либо динамически получаю кратковременные сертификаты из Vault.