Генератор SSH-ключей

RSA 2048 бит соответствует текущим стандартам безопасности и одобрен NIST как минимум до 2030 года. RSA 4096 бит обеспечивает больший запас прочности для ключей, которые будут использоваться в течение многих лет, но он значительно медленнее при операциях квитирования (примерно в 4 раза медленнее, чем 2048-битный). Для большинства сценариев использования — доступа к серверу, GitHub/GitLab, CI/CD-конвейеров — достаточно 2048 бит. Для ключей, используемых в средах с высоким уровнем безопасности или ожидающих использования более 10 лет, используйте 4096 бит. Для лучшего сочетания скорости и безопасности используйте Ed25519.

Парольная фраза шифрует ваш файл с закрытым ключом так, чтобы даже если кто-то получит этот файл, он не смог его использовать без парольной фразы. Когда вы используете ключ, ваш SSH-клиент запрашивает парольную фразу для его расшифровки (ssh-agent может кэшировать расшифрованный ключ, чтобы вы не вводили её каждый раз). Для ключей с пользовательским доступом (от вашего ноутбука к вашим серверам) используйте парольную фразу — она обеспечивает критическую защиту, если ваше устройство будет утеряно или украдено. Для автоматизированных ключей развертывания CI/CD, которые запускаются без участия человека, ключи с защитой парольной фразой непрактичны, и файл ключа должен быть защищен другими средствами (разрешениями файлов, системами управления секретами).

Скопируйте содержимое публичного ключа (начинающееся с "ssh-rsa" или "ssh-ed25519") и добавьте его в файл ~/.ssh/authorized_keys на вашем сервере. Один публичный ключ на строку. Если директория не существует: mkdir -p ~/.ssh && chmod 700 ~/.ssh. Установите правильные разрешения: chmod 600 ~/.ssh/authorized_keys. Самый быстрый способ с вашей локальной машины: ssh-copy-id user@hostname (используя ваш пароль для этой одноразовой настройки). После этого SSH будет автоматически использовать ваш ключ. Ваш закрытый ключ остается только на вашей локальной машине и никогда не загружается никуда.

Комментарий — это метка, встроенная в публичный ключ после данных ключа (например, ssh-ed25519 AAAA... user@laptop). Он не влияет на аутентификацию — он носит чисто описательный характер. Используйте его для идентификации источника ключа, когда вы проверяете authorized_keys на сервере: кто создал этот ключ, с какой машины и для каких целей. Распространенные форматы: user@hostname (по умолчанию), ваш адрес электронной почты или описательная метка типа "ci-deploy-prod-2026". Когда у вас в authorized_keys несколько ключей, осмысленный комментарий — это единственный способ узнать, какой ключ отозвать, если что-то пойдет не так.

Отпечаток (fingerprint) — это хеш SHA-256 публичного ключа, отображаемый в формате Base64 (например, SHA256:abc123...). Это компактный способ идентификации и проверки конкретного ключа. Когда вы впервые подключаетесь к серверу по SSH, сервер показывает вам отпечаток своего ключа хоста — вы проверяете его, чтобы подтвердить, что подключаетесь к правильному серверу. Когда вы загружаете публичный ключ в GitHub, GitLab или другие сервисы, они показывают вам отпечаток. Если отпечаток совпадает с тем, что показывает этот инструмент, значит, ключ был загружен правильно. Вы также можете запустить ssh-keygen -l -f ~/.ssh/id_ed25519 на своей машине для проверки отпечатков локально.

Да. Вся генерация ключей использует Web Crypto API — нативный браузерный API, предоставляющий криптографически безопасные операции, подкрепленные источником энтропии операционной системы. Генерация случайных чисел использует crypto.getRandomValues(), а не небезопасный Math.random(). Сгенерированные ключи эквиваленны по безопасности тем, что производятся с помощью ssh-keygen в командной строке. Ничего не отправляется на какой-либо сервер — пара ключей существует только в вашей сессии браузера.

Никогда не заменяйте существующие authorized_keys — добавьте свой новый публичный ключ как дополнительную запись. Затем откройте вторую SSH-сессию (не закрывая текущую), чтобы протестировать новый ключ. Только после подтверждения работы нового ключа следует удалять старые ключи или изменять политику паролей. Если вы потеряете доступ, вам потребуется консольный доступ к серверу (облачные провайдеры называют это «emergency console» или «rescue mode»), чтобы вручную отредактировать authorized_keys.