Опиши процесс установления доступа к серверу по ssh ключу

Процесс установления SSH-доступа по ключам

Установление доступа к серверу по SSH-ключу — это стандартная и безопасная практика в DevOps, которая заменяет менее безопасную аутентификацию по паролю. Процесс основан на криптографии с открытым ключом и включает несколько этапов.

1. Генерация пары ключей на клиентской машине

Первым шагом является создание пары ключей (приватного и публичного) на компьютере, с которого будет осуществляться подключение. Для этого используется утилита ssh-keygen. Рекомендуется использовать современный алгоритм Ed25519, либо, для совместимости, RSA с длиной не менее 4096 бит.

# Генерация ключа Ed25519 (предпочтительно)
ssh-keygen -t ed25519 -C "your_email@example.com"

# Или генерация RSA ключа
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

В процессе утилита запросит:

• Путь для сохранения файлов (по умолчанию ~/.ssh/id_algorithm, например, ~/.ssh/id_ed25519).
• Парольную фразу (passphrase) для дополнительного шифрования приватного ключа. Это крайне рекомендуется для повышения безопасности.

В результате в директории ~/.ssh/ будут созданы два файла:

• Приватный ключ (например, id_ed25519): Файл без расширения. Должен храниться в секрете, его права доступа должны быть 600 (-rw-------).
• Публичный ключ (например, id_ed25519.pub): Файл с расширением .pub. Его содержимое можно свободно передавать.

2. Копирование публичного ключа на целевой сервер

Публичный ключ необходимо разместить на целевом сервере в специальном файле ~/.ssh/authorized_keys в домашней директории пользователя, под которым планируется вход.

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

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

Эта команда:

1. Подключится к серверу по SSH (используя пароль пользователя username).
2. Проверит существование и корректность прав доступа на каталог ~/.ssh и файл ~/.ssh/authorized_keys.
3. Добавит содержимое вашего публичного ключа в конец файла authorized_keys.

Если ssh-copy-id недоступен, можно выполнить операцию вручную:

# Шаг 1: Скопировать публичный ключ на сервер любым способом (например, через scp)
# Шаг 2: На сервере, убедиться, что существует папка .ssh и файл authorized_keys
mkdir -p ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

# Шаг 3: Добавить ключ в файл
cat /path/to/copied_key.pub >> ~/.ssh/authorized_keys

Критически важны правильные права доступа:

• .ssh/ — 700 (drwx------)
• authorized_keys — 600 (-rw-------)
• Домашняя директория пользователя НЕ должна быть доступна для записи группе/остальным (максимум 755).

3. Настройка SSH-демона на сервере (опционально, но рекомендуется)

Для усиления безопасности следует отредактировать конфигурационный файл SSH-сервера /etc/ssh/sshd_config.

sudo nano /etc/ssh/sshd_config

Ключевые параметры:

PubkeyAuthentication yes    # Разрешить аутентификацию по ключу (обычно уже включено)
PasswordAuthentication no   # ЗАПРЕТИТЬ аутентификацию по паролю после успешной настройки ключей
PermitRootLogin no          # Запретить прямой root-вход (лучше использовать sudo)

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

sudo systemctl reload sshd   # Или restart sshd

Важно: Запрещать аутентификацию по паролю (PasswordAuthentication no) следует ТОЛЬКО после того, как вы убедились, что подключение по ключу работает стабильно и у вас есть альтернативный способ доступа (например, консоль в облаке).

4. Подключение к серверу с клиента

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

ssh username@remote_server_ip

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

# Запустить агент и добавить ключ
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Итог и принцип работы

Процесс аутентификации происходит следующим образом:

1. Клиент инициирует соединение с сервером.
2. Сервер, обнаружив публичный ключ клиента в authorized_keys, отправляет "challenge" (вызов) — случайное сообщение, зашифрованное этим публичным ключом.
3. Клиент расшифровывает "challenge" своим приватным ключом и отправляет ответ обратно.
4. Сервер проверяет ответ. Если он корректен, аутентификация считается успешной.

Преимущества данного метода:

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

В DevOps этот процесс является базовым для управления инфраструктурой, развертывания кода и организации безопасного доступа между серверами.