Как создать и установить SSH-ключ на удалённый сервер

Краткое содержание

• SSH-ключи позволяют входить на удалённые машины без пароля. Парой ключей являются публичный и приватный ключи.
• На Linux создавайте ключи командой ssh-keygen; по умолчанию используется алгоритм Ed25519. Рекомендуется задать passphrase.
• Переносите публичный ключ на сервер через ssh-copy-id или вставьте содержимое файла .pub в ~/.ssh/authorized_keys на сервере.

Что такое SSH-ключ?

SSH-ключ — это криптографическая пара: публичный ключ и приватный ключ. Публичный ключ можно безопасно размещать на сервере. Приватный ключ остаётся на вашей машине и ни с кем не передаётся.

При подключении сервер сравнивает ваш публичный ключ с приватным ключом, который использует клиент. Если пара совпадает, сервер авторизует доступ.

Важно: никогда не разглашайте приватный ключ.

Как сгенерировать SSH-ключ

Откройте терминал и выполните:

ssh-keygen

Команда спросит, куда сохранить ключ и предложит ввести passphrase (парольную фразу). Passphrase добавляет защиту: даже при компрометации приватного ключа без фразы злоумышленник не сможет им воспользоваться.

Если вы хотите входить без запроса пароля к приватному ключу, оставьте passphrase пустым. Но это снижает безопасность.

По умолчанию ssh-keygen создаёт ключ Ed25519, который подходит для большинства случаев. Чтобы явно указать алгоритм, используйте флаг -t, например:

ssh-keygen -t ed25519 -C "your_email@example.com"

Файл с публичным ключом будет иметь суффикс .pub и находиться в каталоге ~/.ssh (например, ~/.ssh/id_ed25519.pub).

Советы по безопасности при создании

• Используйте Ed25519 или, при совместимости проблем, RSA с длиной 3072+ бит.
• Всегда защищайте приватный ключ passphrase, если это возможно.
• Храните приватный ключ с правами 600 (chmod 600).
• Для удобства используйте ssh-agent для кэширования расшифрованного ключа.

Как перенести публичный ключ на удалённый сервер

Есть два основных способа.

1. Быстрее — утилита ssh-copy-id:

ssh-copy-id user@example.com

После ввода пароля утилита добавит ваш публичный ключ в файл ~/.ssh/authorized_keys на целевой машине. Важно: ssh-copy-id копирует публичный ключ, а не приватный.

Подключиться можно так:

ssh user@example.com

2. Вручную. Если ssh-copy-id недоступен, скопируйте содержимое файла ~/.ssh/id_*.pub и вставьте его в ~/.ssh/authorized_keys на удалённом сервере. Пример команды для локального просмотра:

cat ~/.ssh/id_ed25519.pub

На сервере убедитесь в правах:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Если права файлов установлены неверно, SSH откажет в авторизации.

Отладка и типичные ошибки

• “Permission denied (publickey)” — скорее всего, сервер не видит ваш публичный ключ или права неправильные.
• Проверьте, что ключ в authorized_keys в одной строке и без лишних переносов.
• Убедитесь, что вы используете правильный логин (user@host).
• Для подробной информации используйте клиентский режим отладки:

ssh -vvv user@example.com

• SELinux может блокировать доступ. Для RHEL/CentOS проверьте контекст SELinux и, при необходимости, выполните restorecon.

Роли и чек-листы

Разработчик:

• Сгенерировать ключ (ssh-keygen).
• Добавить passphrase (если допускается).
• Добавить публичный ключ в authorized_keys или через ssh-copy-id.
• Проверить подключение: ssh user@host.
• Добавить ключ в ssh-agent: ssh-add ~/.ssh/id_ed25519.

Системный администратор:

• Проверить права на ~/.ssh и authorized_keys на сервере.
• Убедиться в правильном ownership (user:user).
• Настроить /etc/ssh/sshd_config: PubkeyAuthentication yes.
• Перезагрузить sshd при изменениях конфигурации.
• Ограничить доступ по IP или использовать AllowUsers/Match при необходимости.

Малый метод: быстрый чек-лист (Generate → Secure → Deploy → Test)

1. Generate: ssh-keygen (-t ed25519).
2. Secure: chmod 600 приватному ключу; использовать passphrase.
3. Deploy: ssh-copy-id или append public key to authorized_keys.
4. Test: ssh user@host, при проблемах — ssh -vvv.

Когда этот подход не подходит

• Если сервер запрещает вход по ключам (PasswordAuthentication forced) — нужно менять конфигурацию сервера.
• Централизованные инфраструктуры могут требовать управление ключами через IAM/CMDB.
• Для однократного доступа лучше использовать временные одноразовые ключи или bastion-сервер.

Критерии приёмки

• Убедитесь, что команда ssh user@host позволяет войти без ввода пароля.
• На сервере ~/.ssh/authorized_keys содержит корректную строку с публичным ключом.
• Права на ~/.ssh — 700, на authorized_keys — 600 и owner соответствует пользователю.

Краткая справка (глоссарий)

• SSH: Secure Shell — протокол для защищённого доступа к удалённым системам.
• Публичный ключ: часть пары, размещаемая на сервере.
• Приватный ключ: секретная часть, хранится у клиента.
• Passphrase: парольная фраза для защиты приватного ключа.
• ssh-agent: фоновый процесс для кэширования расшифрованных ключей.
• authorized_keys: файл на сервере со списком допустимых публичных ключей.

Решение: стоит ли использовать passphrase (диаграмма)

flowchart TD
  A[Нужна высокая безопасность?] -->|Да| B[Использовать passphrase и ssh-agent]
  A -->|Нет| C[Оставить пустым 'удобство']
  B --> D[Резервное хранение приватного ключа]
  C --> D

Итог

SSH-ключи дают безопасный и удобный способ входа на серверы. Сгенерируйте ключ, защитите приватный ключ passphrase и корректно разместите публичный ключ на сервере. Проверьте права и используйте ssh-agent для ежедневной работы.

Важно: приватный ключ храните в секрете; публичный ключ можно свободно копировать.