MAATRIX / Блог / Настройка SSH на VPS: ключи вместо паролей

Настройка SSH на VPS: ключи вместо паролей

Блог MAATRIX · 2026-07-07

SSH — главный способ управления VPS. Неверная настройка открывает дверь для брутфорса. Переходим на ключи, ограничиваем root и включаем fail2ban.

Первое подключение

Провайдер выдаёт root@IP и пароль. Первый вход: ssh root@IP, смените пароль (passwd) и сразу настройте ключи — до того как IP попадёт в сканеры.

Консоль VNC/KVM в панели MAATRIX — запасной доступ, если SSH сломали конфигом.

AllowUsers deploy admin — whitelist аккаунтов с SSH доступом; даже при утечке пароля другого user вход закрыт.

Bastion host pattern: один VPS принимает SSH из интернета, internal VPS только из bastion subnet.

Если используете несколько администраторов, каждому — отдельный ключ и отдельная строка authorized_keys с комментарием email для быстрого audit при offboarding.

Многофакторная аутентификация PAM поверх ключей оправдана для production admin доступа к финансовым и персональным данным.

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK и США. Оплата картой РФ и по СБП.

Арендовать VPS

SSH-ключи

На локальной машине: ssh-keygen -t ed25519 -C "you@laptop". Публичный ключ (.pub) — на сервер в ~/.ssh/authorized_keys, chmod 600.

ssh-copy-id root@IP — быстрый способ. Несколько ключей — по одному на строку в authorized_keys.

Passphrase на ключ — защита при краже ноутбука; ssh-agent хранит расшифрованный ключ в сессии.

LoginGraceTime 30 и ClientAliveInterval 300 — баланс UX и security против idle sessions.

Match User deploy block в sshd_config — разные политики для admin vs deploy: deploy без TCP forwarding, admin с tunnel.

Jump host (bastion) имеет смысл при десятках internal VPS: один публичный SSH endpoint, internal машины слушают только private VLAN.

Практика показывает: большинство инцидентов на VPS связано не с «слабым железом», а с отсутствием мониторинга, бэкапов и дисциплины обновлений — инфраструктура MAATRIX даёт базу, эксплуатация остаётся на вашей стороне. (Контекст: nastrojka ssh na vps)

sshd_config

В /etc/ssh/sshd_config: PasswordAuthentication no, PermitRootLogin prohibit-password (или no после создания sudo-user).

PubkeyAuthentication yes. MaxAuthTries 3. Перезапуск: systemctl reload sshd — держите вторую сессию открытой при тесте!

Ed25519 предпочтительнее RSA 4096 — короче ключ, быстрее handshake, современная криптография.

Two-factor SSH via pam_google_authenticator — TOTP поверх ключей для high security admin access.

Отключение аутентификации по паролю снижает шум в auth.log на порядок — fail2ban начинает работать эффективнее на оставшихся векторах.

Документируйте шаги настройки в internal wiki или README репозитория infra — через полгода вы забудете, почему выбрали именно такой порт, timeout или размер worker pool. (Контекст: nastrojka ssh na vps)

Пользователь sudo

adduser deploy; usermod -aG sudo deploy. Вход deploy@IP, sudo для админ-задач. Root login отключён.

Деплой приложений от deploy, не от root — меньше ущерб при компрометации процесса.

Отключите X11Forwarding и AllowTcpForwarding если не используете — уменьшает attack surface.

Inventory authorized_keys comment field — email owner каждого ключа для audit who has access.

Для автоматизации Ansible используйте dedicated deploy key без passphrase на CI runner, а интерактивный admin key — с passphrase и ssh-agent локально.

Порт и UFW

Port 2222 в sshd_config — security through obscurity слабая, но снижает шум ботов на 22. UFW allow 2222/tcp перед reload sshd.

ufw enable после allow SSH — иначе потеряете доступ.

Audit: grep 'Accepted publickey' /var/log/auth.log — кто реально заходил; настройте alert на root login attempts после hardening.

Disable password authentication только после verified key login в отдельной сессии — checklist item bold.

Смена порта SSH не заменяет ключи, но уменьшает количество автоматических попыток входа — комбинируйте оба приёма.

fail2ban

apt install fail2ban. Jail [sshd] банит IP после N неудачных попыток. ignoreip — ваш офис/VPN.

fail2ban-client status sshd — список забаненных. Логи /var/log/fail2ban.log.

Backup sshd_config перед изменениями; visudo -c после правок sudoers — syntax error sudo может lock admin.

После hardening SSH сохраните документ recovery: IP, порт, имя sudo-пользователя, location backup authorized_keys и процедура доступа через KVM-консоль MAATRIX.

Регулярно обновляйте OpenSSH server: apt upgrade openssh-server — патчи timing attacks и CVE выходят для sshd так же часто, как для nginx.

Чеклист

  • Ключи работают
  • Пароль отключён
  • Root login запрещён
  • UFW: только SSH, 80, 443
  • fail2ban активен

Раз в квартал проверяйте authorized_keys — удаляйте ключи уволенных сотрудников.

Hardware security keys (FIDO2) через ssh-sk — следующий уровень после ed25519 для critical production.

Проверка конфигурации sshd выполняется командой sshd -t перед reload — синтаксическая ошибка не должна отрезать единственную активную сессию администратора.

При подозрении на компромисс ключей — rotate keys всех пользователей и проверьте crontab, authorized_keys и ~/.ssh на неизвестные записи.

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK и США. Оплата картой РФ и по СБП.

Арендовать VPS

Частые вопросы

Потерял ключ?

Консоль провайдера или reset root в панели.

VPN перед SSH?

Ключи достаточно; bastion — для команд.

ssh-agent?

ssh -A — только доверенные хосты.