SSH-ключи и known_hosts: безопасное подключение к серверу

SSH одновременно решает две разные задачи доверия: сервер доказывает клиенту свою identity через host key, а пользователь — серверу через пароль, public key или другой…

SSH одновременно решает две разные задачи доверия: сервер доказывает клиенту свою identity через host key, а пользователь — серверу через пароль, public key или другой разрешённый метод. Пользовательский ключ нельзя считать безопасным, если проверка сервера отключена.

Пара ключей пользователя

Private key остаётся у владельца, public key устанавливается в authorized_keys на сервере. Современный OpenSSH поддерживает Ed25519; новый ключ создают с отдельным именем и осмысленной меткой, не перезаписывая существующий.

key_dir=$(mktemp -d)
ssh-keygen -t ed25519 -a 64 \
  -f "$key_dir/id_ed25519" \
  -N '' \
  -C 'linux-track-practice'
ssh-keygen -lf "$key_dir/id_ed25519.pub"
stat -c '%a %n' "$key_dir/id_ed25519" "$key_dir/id_ed25519.pub"

Пустая passphrase допустима только в изолированном учебном примере. Рабочий ключ защищают passphrase или аппаратным агентом, ограничивают назначением и ротируют после компрометации. Public key можно распространять; private key нельзя копировать на сервер или отправлять в чат.

Проверка host key

При первом подключении клиент показывает fingerprint сервера. Его нужно сравнить со значением, полученным через доверенный канал от владельца инфраструктуры. После подтверждения ключ попадает в known_hosts. При следующем подключении неожиданная смена вызывает предупреждение: это может быть переустановка сервера, смена IP или атака посредника.

ssh-keygen -F server.example
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub 2>/dev/null || true

Не удаляйте запись known_hosts автоматически. Сначала подтвердите новый fingerprint в панели провайдера, через консоль или у администратора, затем удалите только устаревшую запись командой ssh-keygen -R для точного host.

Диагностика аутентификации

Verbose-режим показывает выбранный config, host key algorithms и предложенные identity без раскрытия private key.

ssh -vvv -o IdentitiesOnly=yes \
  -i "$HOME/.ssh/id_ed25519" user@server.example

Читайте этап: соединение, проверка сервера, предложение public key, ответ сервера. Permission denied (publickey) обычно означает неверного пользователя, отсутствие public key на сервере, права каталога .ssh или policy, а не проблему сети.

Ошибка и диагностика

Опасное исправление — StrictHostKeyChecking=no. Оно убирает подтверждение identity именно тогда, когда соединение можно перехватить. При host key mismatch сохраните fingerprint из ошибки, получите ожидаемый fingerprint независимым способом и проверьте DNS/IP назначения. Только после совпадения обновляйте одну запись.

Практика

Создайте временную Ed25519-пару, выведите fingerprints private/public частей и убедитесь, что они совпадают как одна identity. Проверьте modes. Исследуйте known_hosts через ssh-keygen -F для существующего host, не изменяя файл. Составьте безопасный алгоритм действий при предупреждении REMOTE HOST IDENTIFICATION HAS CHANGED.

Что важно запомнить

Источники