Ключи включены, пароли выключены, а достаточно ли этого: вход root по SSH, sudo без пароля по умолчанию и выбор алгоритма ключа

Виртуальные машины и серверы
1

Вопрос из обсуждения. Небольшой сервер: вход по SSH только ключами (PasswordAuthentication no), ключ RSA-4096. Администратора смутило, что sudo в сессии не спрашивает пароль, и он спросил, всё ли в порядке и нужно ли ещё что-то закрывать.

Что ответили участники (подтверждено автором).

  1. Запретить вход root по SSH. PermitRootLogin no в /etc/ssh/sshd_config (или prohibit-password, если root нужен для автоматизации только по ключу). Вход root это самая перебираемая цель, а действия из-под root не привязываются к человеку в журнале. Задания cron от root после этого работают как прежде: они не зависят от входа.
  2. sudo без пароля это особенность образа некоторых систем (файл в /etc/sudoers.d/ с NOPASSWD). На сервере с одним администратором и входом только по ключу риск ограничен: у того, кто украл ключ, всё равно есть доступ. Но пароль на sudo защищает от случайных команд и от сценариев, где сессию перехватили физически. Убрать NOPASSWD из файла в sudoers.d (через visudo -f), задать пользователю пароль.
  3. Алгоритм ключа. ed25519 вместо RSA-4096: короче, быстрее, без известных слабых мест, поддерживается всеми современными клиентами. Генерировать ssh-keygen -t ed25519 -a 64, добавить на сервер, убедиться во входе, удалить старый ключ из authorized_keys.

Полный минимум для сервера с публичным адресом (sshd_config):

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 20
AllowGroups sshusers
X11Forwarding no

После правки sshd -t и systemctl reload ssh, проверка входа во второй сессии. Проверить /etc/ssh/sshd_config.d/: пакетные файлы там могут включать пароли обратно (в новых Ubuntu есть такой для cloud-init).

Что даёт больше всего. Ключи вместо паролей закрывают перебор. Запрет root и отдельные учётные записи дают трассируемость. Ограничение по адресам и fail2ban уменьшают шум. Второй фактор для sudo или SSH (pam_google_authenticator, аппаратные ключи) следующий шаг для серверов, где утечка ключа критична.

Что не надо делать. Не менять порт «для безопасности» как единственную меру; не отключать журналирование sshd; не давать NOPASSWD: ALL сервисным учётным записям (только конкретные команды).

Параметр описан в документации OpenSSH.