Что такое SSH-ключ и как он работает
SSH-ключевая аутентификация вместо пароля использует пару ключей: private key (у пользователя) и public key (на сервере). Когда пользователь хочет подключиться, сервер шлёт случайный challenge. Клиент подписывает его private key и возвращает серверу. Сервер проверяет подпись по public key и при успехе разрешает вход.
Этот механизм безопаснее пароля, потому что private key никогда не передаётся по сети. Brute force практически невозможен — на подбор 4096-битного RSA или Ed25519 нужны миллионы лет. Но риск идёт от человека: плохо хранимый private key разрушает всю защиту.
Алгоритмы и размеры ключей
Сегодня рекомендуется Ed25519. Он новый, быстрый, короткий (256 бит), но даёт защиту уровня RSA-3072. Если приходится использовать RSA для старых систем, минимум 4096 бит. DSA и RSA-1024 сегодня считаются слабыми и от них нужно отказываться.
В практике Sayt.uz все новые ключи Ed25519, старые RSA-2048 пересоздаются за 90 дней. Команда генерации проста: ssh-keygen -t ed25519 -C "work-email@sayt.uz". Описание (-C) помогает понять владельца ключа и полезно для аудита.
Passphrase — дополнительный уровень защиты
Если файл private key украден, злоумышленник может сразу войти на сервер. Passphrase — это пароль для шифрования ключа. Даже при краже файла без passphrase ключ не работает. Passphrase должен быть сильным (16+ символов) и храниться в менеджере паролей.
Многие считают ввод passphrase неудобным. Но вместе с ssh-agent он вводится один раз и хранится в памяти на время сессии. Правила Sayt.uz: passphrase обязателен для всех production-ключей и рекомендуется для dev-окружений.
ssh-agent и управление ключами
ssh-agent — фоновый сервис, временно хранящий расшифрованные ключи в памяти. Это избавляет от повторного ввода passphrase. Ключи в агент добавляются командой ssh-add и удаляются при завершении сессии.
Важная деталь: ssh-agent forwarding может быть опасным. Если подключиться к удалённому серверу и оттуда прыгнуть на другой, промежуточный сервер получит доступ к памяти агента. Решение — вместо forwarding использовать ProxyJump (-J) или подключение через bastion host.
Ротация и аудит ключей
Ключи нужно периодически менять: персональные рабочие — раз в год, production-ключи — раз в 6 месяцев. Для автоматических систем (CI/CD, deploy bot) — каждые 90 дней. Старый ключ сразу удаляется из authorized_keys на сервере.
Аудит важен: какие ключи есть на каждом сервере и кому они принадлежат, должно быть в реестре. Через Ansible или Terraform authorized_keys управляется автоматически, лишние ключи сразу убираются. Попытки входа пишутся в /var/log/auth.log, аномалии уходят в SIEM.
Практика Sayt.uz
SSH-политика на Sayt.uz: все ключи Ed25519, passphrase обязателен, на сервере PasswordAuthentication=no, root login запрещён, подключение только через bastion, каждое подключение подтверждается two-factor (Duo). Authorized_keys управляется через Ansible, изменения фиксируются в git. Раз в 6 месяцев ротация ключей, ежемесячный аудит-отчёт.