Создание SSH-ключа на Linux: пошаговая инструкция

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

SSH (Secure Shell) — стандартный протокол для безопасного удалённого управления серверами и другими устройствами. Традиционная аутентификация по логину и паролю уязвима для брутфорс-атак. Использование асимметричной криптографии (пара ключей) значительно повышает безопасность: для входа требуется обладать приватным ключом, который никогда не передаётся по сети.

После выполнения этого гайда вы сможете:

• Подключаться к серверам без ввода пароля каждый раз.
• Настроить безопасный доступ для автоматических скриптов (CI/CD, бэкапы).
• Устранить один из основных векторов атак на ваши системы.

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

1. Операционная система: Любой современный дистрибутив Linux (Ubuntu, Debian, CentOS, Fedora, Arch и др.).
2. Пакет OpenSSH: Должен быть установлен. Обычно он есть по умолчанию.
3. Доступ к целевому серверу: Вам понадобится:
   • IP-адрес или доменное имя сервера.
   • Логин пользователя, под которым вы хотите входить (обычно root или ваш обычный пользователь с sudo).
   • Временный пароль от этого пользователя (для первого копирования ключа).
4. Права на локальной машине: Вы должны иметь права на запись в домашнюю директорию (~).

Шаг 1: Проверка наличия SSH-клиента

Откройте терминал и выполните команду для проверки версии клиента OpenSSH:

ssh -V

Пример вывода:

OpenSSH_8.9p1 Ubuntu-3ubuntu0.1, OpenSSL 3.0.2 15 Mar 2022

Если команда не найдена, установите пакет openssh-client:

• Debian/Ubuntu: sudo apt update && sudo apt install openssh-client
• RHEL/CentOS/Fedora: sudo yum install openssh-clients или sudo dnf install openssh-clients

Шаг 2: Генерация пары ключей

Базовый синтаксис команды ssh-keygen:

ssh-keygen -t <тип_ключа> -b <размер_в_битах> -C "<комментарий>"

Рекомендуемый вариант (Ed25519):

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

• -t ed25519 — тип ключа. Ed25519 считается наиболее безопасным и эффективным на сегодня.
• -C "..." — комментарий (обычно email или имя хоста), который добавляется в конец публичного ключа. Полезно для идентификации.
• По умолчанию ключи сохраняются в ~/.ssh/ с именами id_ed25519 (приватный) и id_ed25519.pub (публичный).

Альтернативный вариант (RSA 4096):

ssh-keygen -t rsa -b 4096 -C "login@server-name"

Процесс генерации:

1. Вам предложат указать путь для сохранения файлов. Нажимайте Enter для использования пути по умолчанию (/home/username/.ssh/id_ed25519).
2. Система запросит passphrase (парольную фразу) для защиты приватного ключа на диске.
   • Рекомендация: Задайте сложный пароль. Это защитит ключ, если кто-то получит доступ к вашему компьютеру.
   • Если вы настраиваете доступ для скриптов или не хотите вводить пароль при каждом подключении, оставьте поля пустыми (нажмите Enter дважды).
3. После успешного создания вы увидите отпечаток ключа (fingerprint) и случайную картинку (art) в ASCII.

Шаг 3: Настройка прав доступа (часто не требуется)

Современные версии ssh-keygen автоматически устанавливают правильные права. Но проверить стоит. Права должны быть максимально строгими:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519      # или id_rsa
chmod 644 ~/.ssh/id_ed25519.pub  # или id_rsa.pub

Почему это важно? SSH-клиент откажется использовать ключи с "слабыми" правами доступа (например, если приватный ключ доступен на чтение для группы или всех), чтобы предотвратить компрометацию.

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

Самый простой способ — утилита ssh-copy-id. Она автоматически добавляет содержимое вашего ~/.ssh/id_ed25519.pub в файл ~/.ssh/authorized_keys на целевом сервере.

ssh-copy-id -i ~/.ssh/id_ed25519.pub username@server_ip

• Замените username на ваше имя пользователя на сервере.
• Замените server_ip на IP-адрес или домен сервера.
• Вам будет предложено ввести пароль этого пользователя на сервере (именно тот, который вы планируете заменить ключом).

Что делает команда:

1. Подключается к серверу по SSH с использованием пароля.
2. Создаёт на сервере директорию ~/.ssh (если её нет) с правами 700.
3. Добавляет ваш публичный ключ в конец файла ~/.ssh/authorized_keys (создаёт его при необходимости).
4. Устанавливает правильные права на файлы на сервере.

Если ssh-copy-id отсутствует: Вы можете сделать это вручную, но это менее надёжно из-за возможных проблем с правами.

# 1. Скопировать публичный ключ в буфер обмена (или вывести на экран)
cat ~/.ssh/id_ed25519.pub

# 2. Вручную на сервере (через терминал или консоль управления):
#    mkdir -p ~/.ssh
#    echo "скопированное_содержимое_ключа" >> ~/.ssh/authorized_keys
#    chmod 700 ~/.ssh
#    chmod 600 ~/.ssh/authorized_keys

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

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

ssh username@server_ip

Возможные сценарии:

1. Если вы задали passphrase: Вас попросят ввести парольную фразу (не пароль пользователя на сервере!). После этого вы попадёте на сервер.
2. Если passphrase не задан: Подключение должно установиться мгновенно, без запроса пароля.
3. Если подключение не удалось: Перейдите к разделу "Возможные проблемы".

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

Успешность можно проверить двумя способами:

1. Прямой тест: Выполните команду ssh username@server_ip 'echo "Connection OK"'. Если вы видите Connection OK, подключение работает.
2. Просмотр логов на сервере: На сервере проверьте файл ~/.ssh/authorized_keys. Ваш публичный ключ должен быть в нём (одна строка, начинающаяся с ssh-ed25519 AAAA... или ssh-rsa AAAAB3...).

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

1. Ошибка Permission denied (publickey,password).

• Причина: Сервер не видит ваш ключ или отвергает его.
• Решение:
  • Убедитесь, что вы копировали публичный ключ (.pub), а не приватный.
  • Проверьте, что на сервере в файле ~/.ssh/authorized_keys есть ровно одна строка с вашим ключом (без лишних пробелов или разрывов строк).
  • Проверьте права на сервере: ls -ld ~/.ssh (должно быть drwx------) и ls -l ~/.ssh/authorized_keys (должно быть -rw-------). Исправьте командой chmod при необходимости.

2. Ошибка Could not resolve hostname server_ip: Name or service not known

• Причина: Неправильно указан хост или проблема с DNS.
• Решение: Проверьте IP-адрес или доменное имя сервера. Попробуйте пропинговать его ping server_ip.

3. Ошибка Connection refused или Connection timed out

• Причина: Сервер не принимает SSH-подключения (порт 22 закрыт firewall, служба sshd не запущена, сервер выключен).
• Решение: Проверьте состояние сервера, убедитесь, что служба SSH (sshd) запущена (sudo systemctl status sshd), и что правило firewall разрешает порт 22.

4. Запрос пароля пользователя, а не пароля от ключа (passphrase)

• Причина: Сервер не принимает ваш ключ (см. п.1), поэтому клиент fallback'ается на password-аутентификацию.
• Решение: Исправьте проблему с ключом. После этого запрос пароля от ключа появится только если вы задали passphrase.