Настройка SSH на Linux: создание и использование ключей

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

Подключение к удалённому Linux-серверу по SSH (Secure Shell) является стандартом де-факто для администрирования. Использование криптографических ключей вместо пароля значительно повышает безопасность, защищая от атак перебором (brute-force) и позволяя настраивать автоматизированные задачи (например, через cron или CI/CD-пайплайны). После выполнения этого гайда вы сможете подключаться к серверу, вводя только команду ssh user@host, без запроса пароля.

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

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

1. У вас есть доступ по SSH к целевому серверу (пока ещё по паролю или другому методу).
2. На вашем локальном компьютере (клиенте) установлен пакет openssh-client. Обычно он присутствует по умолчанию в Linux и macOS. В Windows 10/11 можно использовать встроенный клиент OpenSSH или WSL.
3. На целевом сервере запущен и настроен демон sshd (обычно пакет openssh-server). Вы можете проверить это командой:

   sudo systemctl status sshd
   

4. Вы знаете имя пользователя и IP-адрес или доменное имя сервера.

Пошаговая инструкция

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

Откройте терминал на вашей локальной машине. Рекомендуется использовать современный и безопасный алгоритм Ed25519. Если у вас более старая система, можно использовать RSA (минимум 3072 бит).

ssh-keygen -t ed25519 -C "ваше@email.com"

• -t ed25519 — задаёт тип алгоритма.
• -C "комментарий" — произвольный комментарий (часто email), который добавляется в конец публичного ключа для идентификации.

Вам будет предложено:

1. Указать путь для сохранения ключей. По умолчанию: ~/.ssh/id_ed25519 (приватный) и ~/.ssh/id_ed25519.pub (публичный). Нажимайте Enter для использования пути по умолчанию.
2. Ввести парольную фразу (passphrase). Это опционально, но настоятельно рекомендуется для дополнительной защиты приватного ключа. Если вы устанавливаете ключ для автоматических задач, оставьте поле пустым (нажмите Enter дважды).

После выполнения в ~/.ssh/ появятся два файла. Никогда не передавайте приватный ключ (id_ed25519) кому-либо!

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

Существует несколько способов. Самый простой — использовать утилиту ssh-copy-id.

ssh-copy-id username@server_ip_address

• Замените username на имя пользователя на сервере (например, ubuntu, root, debian).
• Замените server_ip_address на IP-адрес или домен сервера.

Вам будет предложено ввести пароль этого пользователя на сервере. Утилита автоматически:

1. Создаст на сервере директорию ~/.ssh (если её нет) с правами 700.
2. Добавит содержимое вашего локального файла ~/.ssh/id_ed25519.pub в конец файла ~/.ssh/authorized_keys на сервере.
3. Установит правильные права на файлы (authorized_keys — 600).

Альтернативный ручной способ (если ssh-copy-id недоступен):

# 1. Вывести содержимое публичного ключа на локальной машине
cat ~/.ssh/id_ed25519.pub

# 2. Скопировать вывод (начиная с "ssh-ed25519 ...") в буфер обмена.
# 3. На сервере (подключившись по паролю) выполнить:
mkdir -p ~/.ssh
echo "скопированная_строка_ключа" >> ~/.ssh/authorized_keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Шаг 3: Проверка конфигурации сервера (дополнительно, но важно)

Для того чтобы сервер принимал ключевую аутентификацию, в его основном конфигурационном файле /etc/ssh/sshd_config должны быть правильно установлены параметры. Подключитесь к серверу (если ещё подключены) и проверьте:

sudo nano /etc/ssh/sshd_config

Убедитесь, что строки выглядят примерно так (значение yes):

PubkeyAuthentication yes
PasswordAuthentication no   # <-- Рекомендуется отключить после успешной настройки ключей!

Внимание: Не отключайте PasswordAuthentication, пока не убедитесь, что ключевой вход работает для всех необходимых пользователей! Иначе вы можете потерять доступ к серверу.

После внесения изменений перезагрузите демон SSH:

sudo systemctl restart sshd

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

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

ssh username@server_ip_address

Если всё настроено верно:

• Вам не будет предложен пароль пользователя username на сервере.
• Если вы задавали парольную фразу (passphrase) при генерации ключа, система запросит её (это локально, на вашей машине). Это нормально.
• Вы попадёте в командную строку сервера.

Шаг 5: (Опционально) Настройка клиента для удобства

Вы можете создать или отредактировать конфигурационный файл ~/.ssh/config на вашем локальном компьютере, чтобы не вводить каждый раз IP-адрес и имя пользователя.

Пример содержимого:

Host myserver
    HostName 192.168.1.100
    User admin
    IdentityFile ~/.ssh/id_ed25519
    Port 22

Теперь для подключения достаточно команды:

ssh myserver

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

1. Успешное подключение: Вы видите приветствие удалённого сервера (Welcome to Ubuntu 22.04...) и командную строку.
2. Проверка аутентификации на сервере: На сервере выполните:

   sudo tail -f /var/log/auth.log
   

   Затем в другом окне попробуйте подключиться. В логе вы увидите строку с Accepted publickey и именем вашего пользователя.
3. Проверка отключения пароля (если делали): Попробуйте подключиться, указав неверный пароль (если он запросится). Подключение должно быть отклонено с ошибкой Permission denied (publickey,password).

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

❌ Ошибка: Permission denied (publickey)

• Причина 1: Неправильные права на файлы в ~/.ssh на сервере.
  • Решение: На сервере выполните:

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

    Убедитесь, что владельцем этих файлов и директории является целевой пользователь (не root).
• Причина 2: Публичный ключ скопирован с ошибками (лишние пробелы, переносы строк).
  • Решение: Проверьте файл ~/.ssh/authorized_keys на сервере. Ключ должен быть одной строкой, начинающейся с ssh-ed25519 AAAA....
• Причина 3: SELinux (на RHEL/CentOS/Fedora) блокирует доступ.
  • Решение: Восстановите правильный контекст SELinux:

    restorecon -Rv ~/.ssh
    

❌ Ошибка: Connection refused или No route to host

• Причина: Сервер не слушает на порту 22 (стандартный порт SSH) или недоступен по сети.
  • Решение:
    1. Проверьте, запущен ли sshd: sudo systemctl status sshd.
    2. Проверьте, слушает ли сервер на порту: sudo ss -tlnp | grep :22.
    3. Проверьте брандмауэр на сервере (sudo ufw status или sudo firewall-cmd --list-all). Разрешите порт 22 (или ваш кастомный порт).

❌ Ошибка: ssh: Could not resolve hostname ...

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

❌ Подключение работает, но sudo на сервере требует пароль

• Причина: Настройки sudoers не разрешают работу без пароля для этого пользователя.
  • Решение: Это отдельная тема настройки sudo. Настройте файл /etc/sudoers через visudo, добавив строку username ALL=(ALL) NOPASSWD: ALL (осторожно, это даёт полные права без пароля).