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

TL;DR

Создайте пару SSH-ключей на Linux командой ssh-keygen, при желании добавьте фразу-пароль. Передайте публичный ключ на сервер через ssh-copy-id или вручную добавьте содержимое файла .pub в ~/.ssh/authorized_keys на удалённой машине. Проверьте права на каталог ~/.ssh (700) и на authorized_keys (600) и отключите парольную аутентификацию после проверки для повышения безопасности.

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

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

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

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

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

Краткое определение: SSH-ключ — пара файлов, применяемая для аутентификации по протоколу OpenSSH.

Генерация SSH-ключа на Linux

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

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

Пояснения:

• Опция -t указывает алгоритм (например, ed25519, rsa).
• -C добавляет комментарий (удобно для идентификации ключа).
• Программа предложит путь для файла (по умолчанию ~/.ssh/id_ed25519) и ввод фразы-пароля (passphrase). Фраза-пароль защищает приватный ключ на диске.

Если вам нужен RSA по совместимости с очень старыми системами:

ssh-keygen -t rsa -b 4096 -C 'your_email@example.com'

Совет: Ed25519 даёт меньше параметров и обычно безопаснее/быстрее; RSA 4096 остаётся совместимым с большинством серверов.

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

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

1. ssh-copy-id — самый простой

ssh-copy-id user@example.com

Команда запросит ваш пароль и добавит содержимое локального публичного ключа в ~/.ssh/authorized_keys на удалённом сервере. После этого войти можно командой:

ssh user@example.com

2. Вручную — если ssh-copy-id недоступна

Сначала скопируйте локальный публичный ключ:

cat ~/.ssh/id_ed25519.pub

Затем на сервере:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
# вставьте содержимое .pub в ~/.ssh/authorized_keys (append)
cat >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Или выполнить безопасный однострочник из локальной машины:

cat ~/.ssh/id_ed25519.pub | ssh user@example.com "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

После успешной передачи проверьте вход:

ssh user@example.com

Если всё настроено корректно, пароль не будет запрошен (если только вы не защищали приватный ключ фразой-паролем).

Важно: ssh-copy-id добавляет публичный ключ в authorized_keys; он не копирует приватный ключ. Приватный ключ должен оставаться локальным.

Частые проблемы и их устранение

• Неправильные права: SSH строго проверяет права доступа. Убедитесь, что каталог ~/.ssh имеет права 700, а файл authorized_keys — 600.
• Отключена аутентификация по ключам на сервере: в /etc/ssh/sshd_config должна быть PermitRootLogin no/without-password и PubkeyAuthentication yes. После изменений перезапустите sshd.
• Неправильный формат ключа: публичный ключ — одна строка, начинающаяся с типа ключа (ssh-ed25519 или ssh-rsa) и далее — длинная строка.
• Несовместимость алгоритма: старый сервер может не поддерживать Ed25519. В этом случае используйте RSA.

Совет по отладке: на клиенте выполните ssh -v user@example.com для подробного вывода и поиска причины отказа.

Когда это не сработает (контрпримеры)

• Сервер полностью запрещает вход по ключам (PubkeyAuthentication no).
• На сервере неправильные права на ~/.ssh или authorized_keys — SSH откажет в приёме ключа.
• Вы потеряли приватный ключ и не имеете резервной альтернативной аутентификации.
• Сетевые фильтры или jump-хосты блокируют соединение.

Альтернативные подходы

• Управление доступом через централизованные решения: LDAP/AD, Kerberos, либо инструменты управления конфигурацией (Ansible, Salt) для массовой установки ключей.
• SSH-агент (ssh-agent) и forwarding: храните приватный ключ на рабочей станции, а агент перенаправляйте через SSH при необходимости, но делайте это осторожно.
• Однаразовые токены или Hardware Security Module (YubiKey) для хранения приватного ключа.

Безопасность и жёсткие рекомендации

• Используйте фразу-пароль для приватного ключа, особенно если ключ хранится на ноутбуке.
• Храните резервную копию приватного ключа в зашифрованном хранилище.
• После успешной проверки отключите PasswordAuthentication в /etc/ssh/sshd_config, чтобы предотвратить взлом по паролю.
• Регулярно проверяйте authorized_keys и удаляйте неиспользуемые записи.

Чек-листы по ролям

Пользователь:

• Сгенерировать пару ключей: ssh-keygen
• Проверить наличие файлов ~/.ssh/id_ и ~/.pub
• Передать публичный ключ через ssh-copy-id или вручную
• Протестировать вход: ssh user@host

Администратор сервера:

• Убедиться, что /etc/ssh/sshd_config разрешает PubkeyAuthentication
• Настроить права: chmod 700 ~/.ssh; chmod 600 ~/.ssh/authorized_keys
• Вести учёт ключей и удалять старые

Аудитор/контроль безопасности:

• Проверить, нет ли повторяющихся ключей между пользователями
• Убедиться, что приватные ключи не хранятся на общедоступных ресурсах

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

• Пользователь входит на сервер без запроса пароля (или с запросом фразы-пароля для приватного ключа).
• На сервере права на ~/.ssh установлены как 700, на authorized_keys как 600.
• В /etc/ssh/sshd_config PubkeyAuthentication включён.
• Нет лишних или неизвестных ключей в authorized_keys.

Словарь (однострочно)

• SSH-ключ: пара файлов (публичный и приватный) для аутентификации по SSH.
• authorized_keys: файл на сервере с разрешёнными публичными ключами.
• ssh-agent: демон, удерживающий приватные ключи в памяти для повторного использования.

Короткая сводка

SSH-ключи — простой и надёжный способ обеспечить безопасный доступ к серверам. Сгенерируйте ключ на клиенте, передайте публичный ключ на сервер, проверьте права и, при желании, отключите парольную аутентификацию. Это уменьшит риск перебора паролей и упростит управление доступом.

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