Пароль при подключении к серверу можно подобрать перебором. SSH-ключ работает иначе: вместо одной строки используется пара файлов — приватный и публичный ключ. Публичный размещается на сервере, приватный остаётся у пользователя и никуда не передаётся. Подобрать приватный ключ перебором практически невозможно, поэтому такая аутентификация устойчивее парольной.
За генерацию, управление и конвертацию пар ключей отвечает утилита ssh-keygen из состава OpenSSH.
OpenSSH поддерживает несколько алгоритмов (параметр -t): rsa, ecdsa и ed25519. Алгоритм dsa устарел и не рекомендуется.
Ed25519 — алгоритм цифровой подписи на основе эллиптической кривой Curve25519. Ключ компактный, проверка подписи быстрая — это рекомендуемый вариант по умолчанию.
Если нужен RSA (например, для совместимости со старыми системами, которые не поддерживают Ed25519), длину ключа стоит задать не менее 3072 бит через параметр -b.
Будем держать в курсе новостей и облачных трендов
Ключ создаётся одной командой:
ssh-keygen -t ed25519
Для RSA:
ssh-keygen -t rsa -b 4096
Утилита запускает интерактивный процесс. По умолчанию приватный ключ сохраняется в ~/.ssh/id<тип>, публичный — в ~/.ssh/id<тип>.pubХ.
Во время генерации ssh-keygen предложит задать passphrase — пароль для дополнительной защиты приватного ключа. Шаг необязательный, но именно passphrase защитит ключ, если файл окажется в чужих руках.
В Windows 10 и 11 есть встроенный клиент OpenSSH: команду ssh-keygen можно запустить прямо в PowerShell без сторонних программ.
Альтернатива — графическая утилита PuTTYgen из пакета PuTTY. Она удобна, если для подключения уже используется клиент PuTTY.
Чтобы сервер принимал вход по ключу, публичный ключ нужно добавить в файл ~/.ssh/authorized_keys соответствующего пользователя.
Делать это вручную необязательно. Утилита ssh-copy-id автоматически копирует публичный ключ на удалённый сервер и добавляет его в authorized_keys.
После копирования публичного ключа проверьте права доступа — без них аутентификация не заработает:
Если права выставлены иначе, sshd отвергнет ключ, даже если сам ключ корректен.
Подключение по ключу:
ssh -i ~/.ssh/id_ed25519 user@host
Если вход не проходит, первым делом проверьте права на ~/.ssh и authorized_keys на сервере — это самая частая причина отказа. Для диагностики запустите ssh с флагом -v:
ssh -v user@host
Режим подробного вывода покажет, на каком шаге аутентификация прерывается: от поиска ключа до его отклонения сервером.
Да. Один и тот же публичный ключ можно добавить в authorized_keys на любом количестве серверов — приватный ключ при этом остаётся один, и его не нужно копировать. Единственное ограничение — если ключ скомпрометирован, отзывать доступ придётся на каждом сервере отдельно, поэтому для разных периметров (личные проекты, прод, чужая инфраструктура) практичнее заводить отдельные пары ключей.
При сопоставимом уровне криптографической стойкости ключ Ed25519 короче (публичный ключ — около 68 символов против нескольких сотен у RSA-4096), а операции подписи и проверки быстрее за счёт более простой арифметики эллиптической кривой. RSA остаётся нужен только там, где Ed25519 не поддерживается — например, в старых версиях OpenSSH или на легаси-оборудовании.
Восстановить сам файл нельзя — приватный ключ не хранится на сервере и не может быть выдан заново. Нужно сгенерировать новую пару, добавить новый публичный ключ в authorized_keys через альтернативный доступ (пароль, консоль провайдера, второй ключ) и удалить из authorized_keys старый публичный ключ, чтобы закрыть доступ по скомпрометированной паре.
Наши специалисты свяжутся с вами в ближайшее время и ответят на все вопросы.
