Как добавить SSH ключи к новому или существующему VPS

SSH-ключи — это криптографические пары ключей: публичный ключ, хранящийся на сервере, и приватный ключ, находящийся на вашем локальном компьютере, — которые подтверждают вашу личность без передачи пароля по сети. При подключении сервер выдаёт криптографическую задачу, которую может решить только ваш приватный ключ, предоставляя доступ при корректном ответе. Этот механизм делает аутентификацию по SSH-ключам принципиально более устойчивой к атакам методом перебора, подстановке учётных данных и перехвату типа «человек посередине» по сравнению с любой схемой на основе паролей.

Это руководство охватывает полный процесс генерации, развёртывания и усиления защиты аутентификации по SSH-ключам как на новых, так и на существующих VPS-инстансах — включая граничные случаи, проблемы с правами доступа и управление несколькими ключами, которые большинство руководств полностью пропускают.

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

Парольная аутентификация передаёт секрет (или его хэш) по сети и полагается на хранение проверяемых учётных данных на сервере. Аутентификация по публичному SSH-ключу никогда не раскрывает приватный ключ — ни при генерации, ни при входе, никогда. Приватный ключ никогда не покидает ваш локальный компьютер.

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

• Автоматизация без участия пользователя — CI/CD-пайплайны, плейбуки Ansible и задания rsync, запускаемые через cron, требуют неинтерактивной аутентификации. Пароли полностью исключают такую возможность.
• Детальный контроль доступа — каждая запись authorized_keys может содержать ограничения command=, from= и no-pty, точно определяющие, что разрешено делать данному ключу.
• Возможность аудита — отдельные ключи можно отозвать без смены общего пароля и нарушения работы всех остальных пользователей или скриптов.
• Устойчивость к фишингу — нет пароля, который можно похитить через поддельную страницу входа.

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

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

• У вас есть работающий VPS или вы находитесь в процессе его создания.
• На вашем локальном компьютере установлен Linux, macOS или Windows с OpenSSH (Windows 10/11 поставляется с OpenSSH по умолчанию; проверьте с помощью ssh -V).
• У вас есть root- или sudo-доступ к целевому серверу.
• Вы понимаете, что потеря приватного ключа без альтернативного способа входа (доступ через консоль, резервный ключ) может навсегда заблокировать вам доступ.

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

Исходная команда ssh-keygen -t rsa -b 4096 надёжна, но не является единственным вариантом. Понимание компромиссов поможет вам сделать правильный выбор для вашей среды.

Ed25519 является рекомендуемым алгоритмом для любого сервера под управлением OpenSSH 6.5 или более поздней версии (выпущена в 2014 году). Используйте RSA 4096 только при подключении к устаревшим системам, не поддерживающим ключи на основе эллиптических кривых.

Часть 1: Добавление SSH-ключей на новый VPS

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

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

Откройте терминал на вашем локальном компьютере. Сгенерируйте пару ключей Ed25519:

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

Если вам нужен RSA по соображениям совместимости:

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

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

Проверьте сгенерированные файлы:

ls -la ~/.ssh/

Вы увидите:

• id_ed25519 — ваш приватный ключ (права доступа должны быть 600; никогда не передавайте этот файл)
• id_ed25519.pub — ваш публичный ключ (можно безопасно копировать куда угодно)

Отобразите публичный ключ для копирования:

cat ~/.ssh/id_ed25519.pub

Вывод выглядит следующим образом:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... your_email@example.com

Скопируйте всю эту строку — вы вставите её в панель управления хостингом.

Шаг 2: Добавление публичного ключа при создании VPS

Войдите в панель управления хостингом. В процессе создания VPS:

1. Выберите операционную систему (Ubuntu 22.04 LTS, Debian 12, Rocky Linux 9 и т.д.).
2. Найдите раздел SSH-ключ или Аутентификация.
3. Вставьте полное содержимое id_ed25519.pub в предоставленное поле.
4. Завершите оставшуюся настройку (тариф, регион, имя хоста).

После загрузки VPS система создания автоматически записывает ваш публичный ключ в /root/.ssh/authorized_keys. Вход по паролю не требуется.

Шаг 3: Подключение к новому VPS

ssh root@your_vps_ip

Если вы использовали нестандартное имя файла ключа, укажите его явно:

ssh -i ~/.ssh/id_ed25519 root@your_vps_ip

Успешное подключение без запроса пароля подтверждает, что ключ был внедрён корректно. Если вы установили парольную фразу, SSH-агент или запрос парольной фразы обработает её локально.

Часть 2: Добавление SSH-ключей на существующий VPS

Если ваш VPS уже работает с парольной аутентификацией, вам необходимо вручную развернуть публичный ключ. Это двухэтапный процесс: скопировать ключ, а затем при необходимости усилить защиту SSH-демона.

Шаг 1: Генерация пары ключей (если у вас её нет)

Следуйте тому же процессу, что и в Шаге 1 Части 1 выше. Если у вас уже есть пара ключей, получите ваш публичный ключ:

cat ~/.ssh/id_ed25519.pub

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

Метод A — ssh-copy-id (рекомендуется)

Утилита ssh-copy-id автоматически создаёт директории, добавляет содержимое файла и устанавливает права доступа:

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@your_vps_ip

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

Метод B — Ручное развёртывание

Используйте этот метод, когда ssh-copy-id недоступен (например, в некоторых средах Windows или ограниченных сетях):

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"

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

Метод C — Вручную через текстовый редактор (резервный вариант)

Войдите на сервер с помощью пароля:

ssh root@your_vps_ip

Создайте директорию .ssh, если она не существует:

mkdir -p ~/.ssh
chmod 700 ~/.ssh

Откройте authorized_keys в текстовом редакторе:

nano ~/.ssh/authorized_keys

Вставьте ваш публичный ключ на новую строку. Сохраните с помощью Ctrl+X, затем Y, затем Enter. Установите права доступа:

chmod 600 ~/.ssh/authorized_keys

Завершите сессию:

exit

Шаг 3: Проверка входа по ключу

Проверьте подключение до внесения каких-либо дальнейших изменений в конфигурацию SSH-демона. Откройте новое окно терминала (не закрывайте текущую сессию):

ssh -i ~/.ssh/id_ed25519 root@your_vps_ip

Если вы подключились без запроса пароля, ключ работает. Переходите к шагам по усилению защиты ниже только после подтверждения этого.

Критическая ошибка: если вы отключите парольную аутентификацию до проверки доступа по ключу, и развёртывание ключа по какой-либо причине не удалось, вы заблокируете себе доступ. Всегда сначала проверяйте.

Шаг 4: Усиление защиты конфигурации SSH-демона

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

nano /etc/ssh/sshd_config

Примените следующие настройки:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password
AuthorizedKeysFile .ssh/authorized_keys
ChallengeResponseAuthentication no
UsePAM yes

Ключевые примечания по этим директивам:

• PermitRootLogin prohibit-password разрешает вход root по ключу, но блокирует вход root по паролю — это лучший компромисс, чем PermitRootLogin no, когда вы ещё настраиваете пользователя sudo без прав root.
• ChallengeResponseAuthentication no отключает клавиатурно-интерактивную аутентификацию, которая может обходить PasswordAuthentication no в некоторых конфигурациях PAM.
• В Ubuntu 22.04+ файл /etc/ssh/sshd_config.d/50-cloud-init.conf может переопределять ваши настройки. При необходимости проверьте и отредактируйте его.

Проверьте синтаксис конфигурации перед перезапуском:

sshd -t

Если ошибок не обнаружено, перезапустите SSH-сервис:

systemctl restart sshd

На системах, использующих ssh.service вместо sshd.service:

systemctl restart ssh

Управление несколькими SSH-ключами и пользователями

В реальных средах редко используется один ключ и один пользователь. Вот как обрабатывать более сложные сценарии.

Добавление ключей для нескольких пользователей

Каждая учётная запись пользователя имеет собственный файл ~/.ssh/authorized_keys. Чтобы добавить ключ для пользователя без прав root с именем deploy:

mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
echo "ssh-ed25519 AAAAC3... deploy@ci-server" >> /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh

Шаг chown часто пропускается и приводит к сбоям аутентификации — SELinux и OpenSSH оба проверяют, что файл authorized_keys принадлежит аутентифицирующемуся пользователю.

Ограничение возможностей ключа

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

command="/usr/bin/rsync --server --daemon .",no-pty,no-agent-forwarding,no-X11-forwarding ssh-ed25519 AAAAC3... backup@monitoring

Этот ключ может выполнять только rsync в режиме демона — ничего больше.

Использование ~/.ssh/config для более удобных подключений

Вместо ввода длинных команд ssh определите псевдонимы хостов на вашем локальном компьютере:

Host myserver
    HostName 203.0.113.45
    User root
    IdentityFile ~/.ssh/id_ed25519
    Port 22

После сохранения в ~/.ssh/config подключайтесь просто с помощью:

ssh myserver

Использование ssh-agent для кэширования парольных фраз

Если ваш приватный ключ защищён парольной фразой (так и должно быть), добавьте его в агент, чтобы не вводить её повторно:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

На macOS добавьте --apple-use-keychain для сохранения между перезагрузками:

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

Распространённые проблемы и устранение неполадок

Проблема: после добавления ключа по-прежнему запрашивается пароль

Запустите подключение с подробным выводом для диагностики:

ssh -vvv root@your_vps_ip

Ищите строки вида Offering public key и Server accepts key. Если ключ предлагается, но отклоняется, проблема почти всегда связана с правами доступа к файлам на сервере.

Проверьте права доступа на сервере:

ls -la ~/.ssh/
stat ~/.ssh/authorized_keys

Необходимые права доступа:

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

Проблема: SELinux блокирует аутентификацию на RHEL/Rocky/AlmaLinux

restorecon -Rv ~/.ssh

Проблема: файл authorized_keys имеет окончания строк Windows (CRLF)

Если вы редактировали файл в Windows и перенесли его, окончания строк могут быть повреждены. Исправьте с помощью:

sed -i 's/r//' ~/.ssh/authorized_keys

Проблема: предлагается неверный ключ

Если у вас несколько ключей, явно укажите нужный:

ssh -i ~/.ssh/id_ed25519 root@your_vps_ip

Или настройте это в ~/.ssh/config, как показано выше.

SSH-ключи в контексте вашей хостинговой инфраструктуры

Аутентификация по SSH-ключам — это не только вопрос одного сервера; она масштабируется на всю вашу инфраструктуру. Если вы управляете парком выделенных серверов, централизованный подход с использованием таких инструментов, как Ansible, Puppet или менеджер секретов (HashiCorp Vault, AWS Secrets Manager) для распространения и ротации авторизованных ключей, является необходимым.

Для команд, запускающих веб-приложения на VPS с cPanel, интерфейс SSH Access в разделе безопасности cPanel предоставляет графический интерфейс для генерации пар ключей и управления ими — полезно для разработчиков, которые не уверенно работают с командной строкой, но нуждаются в безопасном доступе.

Если вы запускаете GPU-интенсивные рабочие нагрузки на инфраструктуре GPU-хостинга, аутентификация по SSH-ключам особенно важна, поскольку эти инстансы часто выполняют длительные задания без участия пользователя. Скомпрометированные учётные данные на GPU-сервере могут привести к значительным несанкционированным расходам на вычисления в дополнение к утечке данных.

Сочетание усиления защиты SSH с действующим SSL-сертификатом для любых веб-сервисов, работающих на том же сервере, одновременно закрывает два наиболее распространённых вектора атак — несанкционированный доступ к оболочке и незашифрованный HTTP-трафик.

Для проектов, использующих виртуальный веб-хостинг с необходимостью SSH-доступа, уточните у провайдера, поддерживает ли он внедрение SSH-ключей через панель управления хостингом, поскольку общие среды часто ограничивают SSH для конкретных пользователей с ограниченным доступом к оболочке.

Ротация ключей и долгосрочное управление ключами

SSH-ключи не истекают автоматически. Без политики ротации ключ, скомпрометированный несколько лет назад, может по-прежнему предоставлять доступ. Установите следующие практики:

• Ротируйте ключи ежегодно или немедленно при подозрении на компрометацию.
• Регулярно проверяйте файлы authorized_keys на всех серверах. Удаляйте ключи, принадлежащие бывшим сотрудникам или выведенным из эксплуатации сервисам.
• Используйте отдельные ключи для каждого устройства — не копируйте один и тот же приватный ключ на несколько ноутбуков или серверов. При потере одного устройства вы отзываете только этот ключ.
• Используйте отдельные ключи для каждой роли — ваш ключ личного доступа, ключ развёртывания CI/CD и ключ автоматизации резервного копирования должны быть разными.
• Документируйте владельцев ключей — ведите реестр, сопоставляющий каждый отпечаток публичного ключа с его владельцем, назначением и датой истечения срока действия.

Чтобы отобразить отпечаток ключа для аудита:

ssh-keygen -lf ~/.ssh/id_ed25519.pub

Контрольный список технических решений

Используйте эту матрицу перед завершением настройки SSH-ключей:

• Алгоритм: используйте Ed25519, если только не подключаетесь к системам старше OpenSSH 6.5; используйте RSA 4096 в качестве запасного варианта.
• Парольная фраза: всегда устанавливайте её для приватных ключей, используемых людьми; сервисные ключи, используемые автоматизацией, могут не иметь её, если хранятся в менеджере секретов.
• Метод развёртывания: используйте ssh-copy-id для интерактивных настроек; используйте управление конфигурацией (Ansible, Puppet) для развёртывания на парке серверов.
• Проверка прав доступа: подтвердите 700 для ~/.ssh/, 600 для authorized_keys и корректное владение перед отключением парольной аутентификации.
• Проверяйте перед блокировкой: всегда проверяйте вход по ключу в отдельном окне терминала перед установкой PasswordAuthentication no.
• Проверка конфигурации демона: запускайте sshd -t перед перезапуском SSH-сервиса для обнаружения синтаксических ошибок.
• Отключение парольной аутентификации: устанавливайте PasswordAuthentication no и ChallengeResponseAuthentication no вместе — одного параметра недостаточно в системах с PAM.
• Политика входа root: предпочитайте PermitRootLogin prohibit-password вместо PermitRootLogin yes; перейдите на пользователя sudo без прав root и установите PermitRootLogin no в качестве окончательного усиленного состояния.
• Ротация ключей: планируйте ежегодную ротацию; отзывайте немедленно при потере устройства или смене персонала.
• Аудит: периодически запускайте grep -r "" /home/*/.ssh/authorized_keys /root/.ssh/authorized_keys для проверки всех авторизованных ключей в системе.

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

Можно ли добавить несколько SSH-ключей на один сервер?

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

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

Вы будете заблокированы в SSH. Для восстановления доступа потребуется обращение к серверу через внеполосный метод: веб-консоль вашего хостинг-провайдера, VNC или среда загрузки для восстановления. Оттуда вы можете повторно включить парольную аутентификацию или добавить новый публичный ключ. Именно поэтому хранение учётных данных консольного доступа в безопасности и отдельно от остальных является необходимым условием.

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

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

Отключает ли добавление SSH-ключа парольный вход автоматически?

Нет. Добавление ключа в authorized_keys включает вход по ключу, но не отключает парольную аутентификацию. Вы должны явно установить PasswordAuthentication no в /etc/ssh/sshd_config и перезапустить SSH-демон для принудительного использования только ключей.

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

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