Перейти к содержанию

SSH: ключи, доступ администраторов и безопасное усиление

SSH — основной протокол удалённого администрирования НАЙС.ОС CLOUD. Согласно опубликованной политике минимального профиля, вход root по SSH запрещён; для доступа используют обычную учётную запись, а повышение привилегий оформляется отдельно. В пакете OpenSSH присутствует собственный 50-niceos.conf — точное содержимое не вложено в архив SPEC, поэтому значения параметров следует устанавливать по фактической конфигурации.

1. Проверить работающий SSH

ss -lntp | grep ':22' || true
systemctl list-unit-files '*ssh*' --no-pager
systemctl status sshd --no-pager
sshd -T | grep -Ei 'permitrootlogin|passwordauthentication|pubkeyauthentication|port|allowusers'

sshd -T выводит итоговые значения для контекста без специальных Match; для конфигураций с Match User/Address может потребоваться sshd -T -C .... Успешная проверка синтаксиса sshd -t не доказывает наличие ключей и сетевого доступа.

2. Генерация ключа на клиенте

Команды ниже выполняются на компьютере администратора, не на сервере:

ssh-keygen -t ed25519 -a 64 -f ~/.ssh/niceos_admin -C 'niceos-admin'
chmod 600 ~/.ssh/niceos_admin

Закрытый ключ храните только в доверенном месте, защищайте парольной фразой и резервной копией по политике организации. Публичную часть niceos_admin.pub можно передавать серверу.

3. Установка публичного ключа

Для подготовленного непривилегированного пользователя на сервере (условное имя admin) убедитесь, что каталог и файлы доступны нужному владельцу:

# На сервере, от имени admin
umask 077
mkdir -p ~/.ssh
chmod 700 ~/.ssh
# Внесите ПРОВЕРЕННЫЙ открытый ключ в ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

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

4. Проверка до отключения парольного входа

С нового терминала:

ssh -i ~/.ssh/niceos_admin -o IdentitiesOnly=yes admin@АДРЕС_СЕРВЕРА

Прежде чем запрещать PasswordAuthentication, проверьте работоспособность ключа для всех обязательных пользователей, sudo, резервную консоль и порядок аварийного доступа. Изменение запретов производится через проверенный drop-in, не переписывая vendor-файл и не нарушая политики root.

5. Верификация конфигурации перед reload

sshd -t
sshd -T | grep -Ei 'permitrootlogin|passwordauthentication|pubkeyauthentication'
systemctl reload sshd

Команду reload выполняйте после просмотра документации текущего unit и проверки sshd -t. Держите первый SSH-сеанс открытым, а новый тестируйте отдельно. Если unit не поддерживает reload, не экспериментируйте с restart без резервной консоли.

6. iptables для SSH

По штатной политике разрешается только явно предусмотренный доступ. Посмотрите iptables -S INPUT, ip6tables -S INPUT; не открывайте 22/tcp всему Интернету, если можно ограничить управляющие адреса. Учтите, что в некоторых средах внешний SSH на нестандартном порту, и это нужно отражать и в sshd, и в firewall.

7. Инцидент: потеря SSH

  1. Не закрывайте оставшиеся сеансы.
  2. Проверьте консоль VM/IPMI.
  3. Сверьте sshd -t, systemctl status, ss, journalctl.
  4. Посмотрите iptables INPUT и OUTPUT, маршрут ответа.
  5. Откатите только последнюю изменение с проверенной резервной копии.

Источники: Core/openssh/SPECS/openssh.spec (Source6: 50-niceos.conf), политика после установки НАЙС.ОС; OpenSSH manual.