SSH-ключи и отключение парольной аутентификации: как защитить сервер WordPress

Почему SSH-ключ лучше пароля

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

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

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

• У каждого администратора должен быть индивидуальный ключ.
• Не отправляйте закрытый ключ через мессенджеры, почту или систему заявок.
• Не используйте один ключ для всех сотрудников: в этом случае невозможно отозвать доступ только одного человека.
• Для серверов обычно выбирают современный тип ключа Ed25519, если его поддерживают клиент и сервер.

Создание отдельного пользователя и SSH-ключа

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

Команды ниже выполняются на локальном компьютере для создания ключа, а затем — на сервере под уже имеющимся администратором. Замените имя пользователя на своё.

• В Linux или macOS ключ можно создать командой ssh-keygen.
• В Windows аналогичные команды доступны в OpenSSH через PowerShell; также можно использовать совместимый SSH-клиент.
• При создании задайте passphrase. Она защищает закрытый ключ, если файл попадёт к посторонним.

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

# На сервере под root или другим администратором
adduser deploy
usermod -aG sudo deploy

# Передайте открытый ключ пользователю
ssh-copy-id deploy@SERVER_IP

Если ssh-copy-id недоступна

Открытый ключ можно добавить вручную в файл ~/.ssh/authorized_keys пользователя deploy. Важно создать каталог с правильными правами и не вставить закрытую часть ключа.

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

install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
nano /home/deploy/.ssh/authorized_keys
chown deploy:deploy /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys

Проверка подключения до отключения паролей

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

Откройте второе окно терминала или отдельную сессию и подключитесь новым пользователем с использованием ключа. Не закрывайте первое подключение, пока не проверите вход, sudo и доступ к нужным файлам.

• Проверьте вход именно с того компьютера или VPN, с которого в дальнейшем будете администрировать сервер.
• Убедитесь, что SSH-клиент использует правильный ключ: ssh -i ~/.ssh/имя_ключа deploy@SERVER_IP.
• Выполните sudo -v или другую безопасную команду sudo и проверьте правильность настроенных прав.
• Если подключение не работает, посмотрите подробный журнал клиента с параметром -v и журналы SSH на сервере.

ssh -i ~/.ssh/id_ed25519 deploy@SERVER_IP
sudo -v

# Проверка конфигурации sshd перед перезапуском
sudo sshd -t

Почему не следует сразу закрывать старую сессию

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

• Не редактируйте конфигурацию без резервной копии.
• Применяйте изменения после проверки синтаксиса.
• Для критически важных серверов планируйте работы на окно обслуживания.

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup
sudo sshd -t

Как отключить root и парольную аутентификацию

Основные параметры SSH обычно находятся в /etc/ssh/sshd_config, но конкретная система также может подключать фрагменты из каталога /etc/ssh/sshd_config.d/. Проверьте эффективные настройки и убедитесь, что более поздний фрагмент конфигурации не переопределяет ваши параметры.

После проверки входа под отдельным пользователем добавьте или измените следующие директивы. Значение PasswordAuthentication no запрещает именно парольный способ входа через SSH.

• PermitRootLogin no — запрещает прямой вход по SSH под root.
• PasswordAuthentication no — отключает вход по паролю.
• PermitEmptyPasswords no — запрещает вход учётным записям с пустым паролем.
• AllowUsers deploy — ограничивает SSH-доступ указанным пользователем.

PermitRootLogin no
PasswordAuthentication no
PermitEmptyPasswords no
AllowUsers deploy

Осторожно с KbdInteractiveAuthentication

Некоторые системы или схемы многофакторной аутентификации используют keyboard-interactive вместо классической парольной аутентификации. Не отключайте KbdInteractiveAuthentication механически, если через него работает MFA или другой необходимый механизм входа. Сначала выясните, какой способ использует ваша конфигурация.

• Если MFA не используется и вы хотите полностью убрать интерактивный вход по паролю, параметр можно отключить после тестирования.
• После изменений выполните sshd -t.
• Перечитайте эффективную конфигурацию, если в системе подключено много фрагментов.

sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|kbdinteractiveauthentication|allowusers'

Применение изменений и ограничение доступа с помощью firewall

После редактирования конфигурации проверьте её синтаксис и перезагрузите службу SSH. В зависимости от дистрибутива служба может называться ssh или sshd. Используйте reload, если он доступен: это позволяет применить конфигурацию без необоснованного разрыва активных сессий.

Дополнительный уровень защиты — ограничить доступ к SSH с помощью firewall. Лучший вариант — разрешить порт только с фиксированных IP-адресов офиса, VPN или административной сети. Изменение стандартного порта может уменьшить количество записей в журналах, но не заменяет ключи, firewall и отключение паролей.

• Перед включением firewall разрешите SSH с вашего текущего IP-адреса или VPN.
• Не ограничивайте доступ только по IP, если адрес провайдера часто меняется и резервного канала нет.
• Проверьте правила со второго подключения, а не после завершения текущей сессии.
• Fail2ban может уменьшить количество повторных попыток, но не заменяет ключевую аутентификацию и firewall.

sudo sshd -t
sudo systemctl reload ssh
# В некоторых системах название службы отличается:
# sudo systemctl reload sshd

# Пример для UFW: замените адрес на свой или адрес VPN
sudo ufw allow from ADMIN_IP to any port 22 proto tcp
sudo ufw enable
sudo ufw status verbose

Типичные ошибки при настройке SSH

Проблемы чаще всего возникают не из-за самого алгоритма ключей, а из-за прав на файлы, неправильного пользователя или блокировки firewall. Проверяйте проблему поэтапно, не внося сразу много изменений.

• Открытый ключ добавлен в /root/.ssh/authorized_keys, хотя подключение выполняется как deploy.
• Каталог .ssh или authorized_keys принадлежит root либо доступен для записи другим пользователям.
• В конфигурации есть ошибка, поэтому службу SSH не удаётся перезагрузить.
• В AllowUsers нет административной учётной записи или указано неправильное имя.
• Firewall разрешает SSH не с того IP-адреса, который вы фактически используете.
• Все ключи сотрудников скопированы в одну учётную запись без меток и контроля.
• Единственный закрытый ключ хранится на незашифрованном или общем компьютере.

namei -l /home/deploy/.ssh/authorized_keys
sudo journalctl -u ssh --no-pager -n 50
ssh -v deploy@SERVER_IP

Что делать после увольнения администратора

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

• Используйте комментарии в конце строки ключа: имя, устройство или дату.
• Регулярно проводите инвентаризацию authorized_keys.
• Для командной среды рассмотрите централизованное управление доступом и краткосрочные учётные данные.
• Не удаляйте последний рабочий ключ, пока не проверите другой.

Что ещё важно для сервера WordPress и Elementor

Защита SSH не заменяет обновление WordPress, тем, плагинов, PHP и самой операционной системы. Если злоумышленник получил доступ к панели WordPress или уязвимому плагину, SSH-ключи не устранят последствия компрометации сайта.

Административная SSH-учётная запись должна получать только те права, которые необходимы для обслуживания. Не запускайте веб-сервер и процессы PHP от root, не храните закрытые ключи в каталоге сайта и не добавляйте ключи в резервные копии, доступные через веб.

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

• Включите многофакторную защиту для панели WordPress и учётных записей хостинга.
• Обновляйте Elementor, WordPress, плагины, тему и системные пакеты после проверки совместимости.
• Ограничивайте права файловой системы и не используйте общие административные учётные записи.
• Храните резервные копии отдельно от сервера и проверяйте их восстановление.
• Обеспечьте аварийный доступ через консоль провайдера или документированный процесс восстановления.