Настройка SSH-ключей на Linux: пошаговое руководство

Введение / Зачем это нужно

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

Требования / Подготовка

Перед началом убедитесь, что:

• У вас есть доступ к Linux-машине (клиенту) с установленным пакетом openssh-client. Обычно он предустановлен в большинстве дистрибутивов.
• У вас есть учётная запись и пароль для доступа на целевой сервер по SSH.
• Вы знакомы с базовыми командами терминала и редактированием файлов (например, с помощью nano или vim).

Если openssh-client не установлен, установите его:

Для Ubuntu/Debian:

sudo apt update && sudo apt install openssh-client

Для CentOS/Fedora:

sudo dnf install openssh-clients

Шаг 1: Генерация SSH-ключей

На клиентской машине откройте терминал и выполните команду:

ssh-keygen -t ed25519 -C "ваш_email@example.com"

Рекомендуется использовать алгоритм ed25519 как современный и безопасный. Если ваша система не поддерживает, можно использовать rsa с длиной 4096 бит:

ssh-keygen -t rsa -b 4096 -C "ваш_email@example.com"

Команда запросит место сохранения ключей (по умолчанию ~/.ssh/id_ed25519 или ~/.ssh/id_rsa) и парольную фразу (passphrase). Для автоматизации можно оставить пустым, но для безопасности рекомендуется задать сложную парольную фразу.

После выполнения в каталоге ~/.ssh/ появятся два файла: приватный ключ (без расширения или с .pem) и публичный ключ (с .pub).

Шаг 2: Копирование публичного ключа на сервер

Самый простой способ – использовать утилиту ssh-copy-id:

ssh-copy-id пользователь@сервер

Замените пользователь на ваше имя пользователя на сервере, а сервер на IP-адрес или домен. Вас попросят ввести пароль для завершения копирования.

Если ssh-copy-id недоступен, скопируйте ключ вручную:

1. Просмотрите содержимое публичного ключа:

   cat ~/.ssh/id_ed25519.pub
   

2. Скопируйте вывод (начинается с ssh-ed25519 ...).
3. На сервере, в сессии SSH, откройте или создайте файл ~/.ssh/authorized_keys и вставьте скопированную строку.

   mkdir -p ~/.ssh
   echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI..." >> ~/.ssh/authorized_keys
   

Убедитесь, что файл authorized_keys содержит только ваши ключи, по одному на строку.

Шаг 3: Настройка прав доступа на сервере

Корректные права доступа критически важны для работы SSH с ключами. На сервере выполните:

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

Если каталог .ssh или файл authorized_keys принадлежат другому пользователю, измените владельца:

chown -R $USER:$USER ~/.ssh

Примечание: эти команды выполняются на сервере, не на клиенте.

Шаг 4: Тестирование подключения

Попробуйте подключиться к серверу с клиента:

ssh пользователь@сервер

Если вы задали парольную фразу при генерации ключа, вас попросят ввести её. В противном случае подключение должно установиться без запроса пароля.

Чтобы убедиться, что используется ключ, добавьте флаг -v для отладки:

ssh -v пользователь@сервер

В выводе ищите строки про Offering public key и Authentication succeeded.

Шаг 5: Использование SSH-агента для управления ключами (опционально)

Если у вас несколько ключей или вы задали парольную фразу, удобно использовать ssh-agent для кэширования. Запустите агент и добавьте ключ:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

После этого в течение сессии агента парольная фраза не будет запрашиваться повторно. Для автоматического запуска агента при входе в систему добавьте команды в файл ~/.bashrc или ~/.profile.

Проверка результата

Успешное подключение без запроса пароля (или только с запросом парольной фразы, если она задана) указывает на правильную настройку. Также вы можете проверить на сервере в ~/.ssh/authorized_keys наличие вашего публичного ключа.

Дополнительно, выполните на клиенте:

ssh-add -l

Это покажет список ключей, добавленных в агент.

Возможные проблемы

• Ошибка "Permission denied (publickey)": Проверьте права на сервере: ~/.ssh должно быть 700, authorized_keys – 600. Убедитесь, что публичный ключ скопирован полностью и без изменений.
• Ключ не предлагается: Убедитесь, что клиент использует правильный ключ. Можно указать ключ явно: ssh -i ~/.ssh/id_ed25519 пользователь@сервер. Также проверьте, что в ~/.ssh/config нет переопределений.
• SELinux или AppArmor блокируют доступ: На некоторых системах с SELinux (CentOS, RHEL) может потребоваться настройка контекстов. Используйте restorecon -Rv ~/.ssh на сервере.
• Парольная фраза забыта: Если вы забыли парольную фразу, сгенерируйте новую пару ключей и замените публичный ключ на сервере.

Для диагностики используйте ssh -v для подробного вывода.