Как загрузить публичный SSH ключ на существующий VPS

SSH публичный ключ — это криптографические учётные данные, хранящиеся в ~/.ssh/authorized_keys на удалённом сервере, которые предоставляют доступ любому клиенту, владеющему соответствующим приватным ключом, — без передачи пароля по сети. Загрузка публичного ключа на существующий VPS заменяет или дополняет аутентификацию на основе пароля асимметричной криптографией, устраняя поверхность атаки, которую используют кампании по перебору паролей и подстановке учётных данных.

Это руководство охватывает все этапы процесса: генерацию ключей, ручные и автоматизированные методы загрузки, усиление прав доступа, настройку sshd_config, управление несколькими ключами и распространённые сбои, с которыми сталкиваются даже опытные администраторы.

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

Прежде чем вводить какую-либо команду, стоит разобраться в криптографических механизмах. При аутентификации с помощью пары ключей сервер выдаёт запрос, зашифрованный вашим публичным ключом. Только владелец соответствующего приватного ключа может расшифровать и подписать ответ. Никакой секрет никогда не передаётся — в отличие от аутентификации по паролю, где учётные данные передаются по сети (даже если они обёрнуты в TLS).

Практический вывод: в любой среде VPS Хостинга, доступной из публичного интернета, SSH-ключи — это не опциональное усиление безопасности, а базовый минимум.

Предварительные требования

• Существующий VPS, доступный по SSH (в настоящее время работает вход по паролю или существующему ключу)
• Локальная машина под управлением Linux, macOS или Windows с OpenSSH или PuTTY
• Достаточные привилегии на VPS для записи в домашний каталог целевого пользователя
• Базовые навыки работы с терминалом и текстовым редактором, например nano или vim

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

Если у вас уже есть пара ключей по пути ~/.ssh/id_ed25519 или ~/.ssh/id_rsa, пропустите этот шаг. В противном случае сгенерируйте её сейчас.

Выбор подходящего алгоритма

Ed25519 — современный стандарт. Используйте RSA 4096 только при подключении к устаревшим серверам, которые не поддерживают Ed25519.

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

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

Генерация пары ключей RSA 4096 (для устаревших систем):

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

В процессе генерации ключей вам будет предложено указать путь сохранения и необязательную кодовую фразу. Принять путь по умолчанию (~/.ssh/id_ed25519) подходит для большинства пользователей. Всегда устанавливайте кодовую фразу — она шифрует приватный ключ на диске с использованием AES-256, поэтому кража ноутбука не означает автоматической компрометации сервера.

В результате создаются два файла:

~/.ssh/id_ed25519 — ваш приватный ключ. Никогда не передавайте его, не копируйте на сервер, не фиксируйте в системе контроля версий.
~/.ssh/id_ed25519.pub — ваш публичный ключ. Его можно свободно распространять.

Отобразите публичный ключ, чтобы скопировать его:
cat ~/.ssh/id_ed25519.pub
Вывод будет выглядеть примерно так:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... your_email@example.com
Скопируйте всю строку целиком, включая префикс алгоритма и комментарий в конце.
Шаг 2: Вход на VPS
Подключитесь к VPS с помощью текущего метода аутентификации:
ssh root@your_vps_ip
Замените your_vps_ip на фактический IPv4 или IPv6 адрес вашего сервера. Если вы управляете учётной записью не-root пользователя, замените root на соответствующее имя пользователя. На Выделенных серверах, где может быть несколько учётных записей пользователей, всегда предпочтительнее развёртывать ключи для не-root пользователя и использовать sudo для повышения привилегий.
Шаг 3: Подготовка каталога .ssh
После входа в систему проверьте или создайте каталог .ssh для целевого пользователя:
mkdir -p ~/.ssh
chmod 700 ~/.ssh
Права доступа 700 (rwx------) обязательны. OpenSSH молча откажется использовать authorized_keys, если каталог .ssh доступен для записи группе или всем пользователям. Это одна из наиболее распространённых причин сбоя аутентификации по ключу после в остальном корректной настройки.
Шаг 4: Добавление публичного ключа в authorized_keys
Метод А: Ручная вставка (универсальный)
Откройте или создайте файл authorized_keys:
nano ~/.ssh/authorized_keys
Вставьте ваш публичный ключ на новую строку. Каждая строка в этом файле представляет один авторизованный ключ. Сохраните с помощью Ctrl+X, затем Y, затем Enter.
Установите правильные права доступа:
chmod 600 ~/.ssh/authorized_keys
Права доступа 600 (rw-------) гарантируют, что только владелец файла может читать или записывать его. OpenSSH строго соблюдает это требование.
Метод Б: ssh-copy-id (рекомендуется для быстрой настройки)
Если на вашей локальной машине доступна утилита ssh-copy-id (стандартная в Linux и macOS), эта единственная команда автоматически создаёт каталог, добавляет ключ и устанавливает права доступа:
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@your_vps_ip
Вам будет предложено ввести текущий SSH-пароль один раз. После этого вход по ключу будет активен. Флаг -i явно указывает, какой публичный ключ загружать, предотвращая случайную загрузку неверного ключа.
Метод В: Однострочная команда через cat и pipe (для скриптов)
Полезно в конвейерах автоматизации или когда ssh-copy-id недоступна:
cat ~/.ssh/id_ed25519.pub | ssh root@your_vps_ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"
Этот подход безопасен с точки зрения идемпотентности в том смысле, что он добавляет ключ, а не перезаписывает файл, сохраняя все существующие авторизованные ключи.
Шаг 5: Проверка правильности владельца файла
Часто упускаемая из виду проблема: если вы создали каталог .ssh или файл authorized_keys от имени root при настройке учётной записи другого пользователя, владелец будет неверным, и SSH молча отклонит ключ.
Проверьте владельца:
ls -la ~/.ssh/
В выводе должно быть указано имя целевого пользователя как владельца и группы для каталога и файла:
drwx------ 2 alice alice 4096 Jan 15 10:00 .ssh
-rw------- 1 alice alice  571 Jan 15 10:00 .ssh/authorized_keys
Если владелец неверный, исправьте это (выполните от имени root):
chown -R alice:alice /home/alice/.ssh
Шаг 6: Проверка входа по SSH-ключу
Завершите текущий сеанс:
exit
Переподключитесь с явным указанием ключа для подтверждения настройки:
ssh -i ~/.ssh/id_ed25519 root@your_vps_ip
Если вход выполняется без запроса пароля (или запрашивается только локальная кодовая фраза ключа), настройка выполнена правильно. Если по-прежнему запрашивается пароль сервера, перейдите к разделу устранения неполадок ниже.
Шаг 7: Усиление конфигурации SSH-демона
После подтверждения работоспособности входа по ключу отключите аутентификацию по паролю, чтобы полностью устранить вектор атаки методом перебора паролей.
Откройте файл конфигурации SSH-демона:
nano /etc/ssh/sshd_config
Найдите и установите следующие директивы. Если строка закомментирована символом #, удалите # и установите значение:
PasswordAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PermitRootLogin prohibit-password
ChallengeResponseAuthentication no
UsePAM yes
Примечание о PermitRootLogin prohibit-password: этот параметр разрешает вход root исключительно по ключу, блокируя доступ root по паролю, но сохраняя возможность аутентифицированных по ключу сеансов root. Для максимального усиления безопасности установите значение no и используйте не-root пользователя с sudo.
В некоторых дистрибутивах дополнительный файл конфигурации может переопределять ваши настройки. Проверьте наличие переопределений:
grep -r "PasswordAuthentication" /etc/ssh/sshd_config.d/
Если какой-либо файл в этом каталоге устанавливает PasswordAuthentication yes, отредактируйте или удалите его.
Проверьте синтаксис конфигурации перед перезапуском:
sshd -t
Чистый вывод (без ошибок) означает, что можно безопасно перезагрузить конфигурацию. Примените изменения:
systemctl restart sshd
Критическое предупреждение: Не закрывайте текущий SSH-сеанс, не открыв второй терминал и не убедившись, что вы по-прежнему можете войти с помощью ключа. Перезапуск sshd с неверно настроенным файлом или до того, как ваш ключ заработает, заблокирует вам доступ. Большинство Панелей управления VPS предоставляют аварийную консоль (доступ KVM/VNC) для восстановления, но гораздо лучше полностью избежать этой ситуации.
Шаг 8: Управление несколькими ключами и серверами с помощью ~/.ssh/config
При управлении несколькими серверами — что характерно для сред разработки/продакшена или при администрировании нескольких Выделенных серверов — файл конфигурации SSH-клиента избавляет от необходимости запоминать IP-адреса, имена пользователей и пути к ключам.
Создайте или отредактируйте ~/.ssh/config на вашей локальной машине:
nano ~/.ssh/config
Пример конфигурации для нескольких хостов:
Host production-vps
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    Port 22

Host staging-vps
    HostName 203.0.113.20
    User deploy
    IdentityFile ~/.ssh/id_ed25519_staging
    Port 2222

Host legacy-server
    HostName 203.0.113.30
    User admin
    IdentityFile ~/.ssh/id_rsa_legacy
    PubkeyAcceptedKeyTypes +ssh-rsa
Установите правильные права доступа на файл конфигурации:
chmod 600 ~/.ssh/config
Теперь вы можете подключаться с помощью удобных псевдонимов:
ssh production-vps
ssh staging-vps
Директива PubkeyAcceptedKeyTypes +ssh-rsa в записи для устаревшего сервера важна: новые клиенты OpenSSH (8.8+) по умолчанию отключают RSA-SHA1. Без этого переопределения подключения к старым серверам будут завершаться с непонятной ошибкой «no matching host key type».
Устранение неполадок: почему аутентификация по SSH-ключу не работает
Даже при правильной настройке несколько факторов среды могут привести к тому, что аутентификация по ключу молча переключится на запрос пароля:
Неверные права доступа на .ssh или authorized_keys:
Выполните ls -la ~/.ssh/ на сервере. Каталог должен иметь права 700, а файл — 600. Любые более широкие права заставят OpenSSH игнорировать файл.
Несоответствие контекста SELinux или AppArmor:
На системах RHEL/CentOS/AlmaLinux с принудительным применением SELinux файл authorized_keys может иметь неверный контекст безопасности. Восстановите его с помощью:
restorecon -Rv ~/.ssh
Неверный домашний каталог пользователя:
Если домашний каталог пользователя доступен для записи не только владельцу, SSH откажет в аутентификации по ключу. Проверьте с помощью:
ls -ld ~
Сам домашний каталог не должен быть доступен для записи группе или всем пользователям.
Директива AuthorizedKeysFile указывает на другое место:
Некоторые дистрибутивы настраивают AuthorizedKeysFile на нестандартный путь (например, /etc/ssh/authorized_keys/%u). Проверьте активную настройку:
sshd -T | grep authorizedkeysfile
Несколько ключей и конфликты ssh-agent:
Если ssh-agent запущен с несколькими загруженными ключами, сервер может отклонить соединение после слишком большого количества неудачных попыток с ключами до того, как будет опробован правильный. Используйте -i для явного указания ключа или настройте IdentitiesOnly yes в ~/.ssh/config.
Брандмауэр или fail2ban блокирует ваш IP:
Если вы ранее несколько раз неудачно пытались войти, правила fail2ban или ufw/iptables могли временно заблокировать ваш IP. Проверьте с помощью:
fail2ban-client status sshd
Ротация и отзыв SSH-ключей
Ротация ключей — это практика обеспечения безопасности, которой часто пренебрегают. Чтобы отозвать конкретный ключ, откройте ~/.ssh/authorized_keys на сервере и удалите соответствующую строку. Каждая строка — это один ключ; её удаление немедленно отзывает доступ для владельца этого приватного ключа, не затрагивая другие авторизованные ключи.
В целях аудита используйте отдельные комментарии для каждого ключа (часть после материала ключа, например alice@workstation-2024), чтобы можно было определить, какой ключ принадлежит какому человеку или устройству. Когда сотрудник увольняется или устройство выводится из эксплуатации, найдите его ключ по комментарию и удалите его.
Чтобы сменить собственный ключ, сгенерируйте новую пару, добавьте новый публичный ключ в authorized_keys, убедитесь, что вход с новым ключом работает, затем удалите запись старого ключа.
Практический контрольный список

По умолчанию генерируйте ключи Ed25519; используйте RSA 4096 только для совместимости с устаревшими серверами
Всегда защищайте приватный ключ надёжной кодовой фразой
По возможности используйте ssh-copy-id для быстрого и безошибочного развёртывания ключей
Убедитесь, что права доступа на каталог .ssh установлены 700, а на authorized_keys — 600

Часто задаваемые вопросы

Можно ли добавить несколько SSH публичных ключей к одной учётной записи пользователя VPS?

Да. Каждая строка в ~/.ssh/authorized_keys является независимым авторизованным ключом. Добавляйте по одному ключу на строку. Это стандартный подход для предоставления доступа нескольким администраторам или с нескольких устройств — каждый человек или устройство владеет уникальным приватным ключом, а отзыв осуществляется на уровне строки.

Что произойдёт, если я потеряю приватный ключ после отключения аутентификации по паролю?

Вы будете заблокированы в SSH. Для восстановления доступа потребуется использовать внеполосный консольный доступ вашего хостинг-провайдера (KVM/VNC), который доступен через большинство панелей управления VPS Хостинга. Через консоль повторно включите PasswordAuthentication yes в /etc/ssh/sshd_config, перезапустите sshd и загрузите новый ключ. Именно поэтому проверка входа по ключу перед отключением паролей является обязательной.

Поддерживается ли Ed25519 на всех серверах?

Ed25519 требует OpenSSH 6.5 или более поздней версии (выпущена в 2014 году). Любой современный дистрибутив Linux — Ubuntu 18.04+, Debian 9+, CentOS 7+, AlmaLinux 8+ — поддерживает его нативно. Только действительно устаревшие системы требуют использования RSA в качестве запасного варианта.

Следует ли использовать одну и ту же пару SSH-ключей для каждого управляемого сервера?

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

Влияет ли загрузка SSH-ключа на мои SSL-сертификаты или конфигурацию веб-сервера?

Нет. SSH-ключи управляют терминальным доступом к операционной системе и полностью отделены от TLS/SSL-сертификатов, используемых веб-серверами (Apache, Nginx) для HTTPS. Они используют разные порты (22 и 443), разные форматы ключей и разные цепочки доверия. Изменение одного никак не влияет на другое.