Сеть / Ступень 10 из 14 · шаг 8 из 9

Оставь только разрешённый SSH-вход

~25 мин

Не запущена Запускается обычно ~20 с

Ситуация

На машине работает отдельный учебный SSH-сервер — служба lab-sshd.service. Он слушает 127.0.0.1:2222 и читает свой файл настроек /srv/ssh-lab/sshd_config; системный sshd тут ни при чём. Через этот сервер входит служебная учётная запись deploy по ключу: клиент настроен в ~/ssh-lab/config, вход — ssh -F ~/ssh-lab/config training.

Проверка безопасности показала, что сервер пускает слишком многих: по паролю, по вопросам сервера и даже root.

Задача

Сервер пускает только по ключу: ни пароль, ни вопросы сервера войти не дают.
Root на этот сервер не входит — даже с ключом, который работал раньше, — а пароль сервер не предлагает.
Новые настройки действуют: lab-sshd.service перезапущена после правки.
deploy входит новым подключением: ssh -F ~/ssh-lab/config training id -un печатает deploy.
Всё остальное не тронуто: прочие строки настроек, ключи, файлы в ~/ssh-lab и системный SSH.

Ограничения

Правь значения в /srv/ssh-lab/sshd_config обычными строками, без Include и Match.
Перезапускай только lab-sshd.service; системный ssh.service и /etc/ssh не трогай.

Нужные инструменты уже установлены. Интернета на машине нет.

Цели лабы

0 из 5

Пароль, keyboard-interactive и root запрещены, вход только по ключу — ещё не проверялась
Исправленная конфигурация работает в новом запуске lab-sshd — ещё не проверялась
Свежий вход deploy по выданному ключу проходит — ещё не проверялась
Root с прежде рабочим ключом получает отказ, пароль не предлагается — ещё не проверялась
Остальные настройки, ключи и системный SSH не тронуты — ещё не проверялась

Подсказки

открыто 0 из 3 · открываются по одной

Подсказка 1

Показать решение после 3 неудачных проверок

Для запуска машины нужен вход

Машина запускается на твой аккаунт, там же хранится прогресс. Читать можно без входа.

После входа вернёшься на эту лабу.

Безопасность · подобрано по лабе

sshd — SSH-сервер

Шпаргалка

$_ — вставить в терминал

sudo sshd -t проверить синтаксис конфига
sudo sshd -T | grep -i permitroot действующее значение параметра
sudo systemctl reload ssh применить без разрыва сессий
ss -tlnp | grep :22 слушает ли порт
journalctl -u ssh -f логи подключений в реальном времени

Главный конфиг — /etc/ssh/sshd_config (+ сниппеты в /etc/ssh/sshd_config.d/). Безопасная база:

PermitRootLogin no
PasswordAuthentication no         # только ключи
PubkeyAuthentication yes
Port 22

Применить изменения безопасно (не обрывая текущую сессию):

bash

sudo sshd -t                      # проверить синтаксис конфига
sudo sshd -T | grep -i permitroot # показать ДЕЙСТВУЮЩИЕ значения (важно!)
sudo systemctl reload ssh         # применить (юнит ssh)

Важно. Меняя SSH-конфиг удалённо, держи второй открытый сеанс — так ошибка не закроет доступ к серверу. Страховка с авто-откатом по таймеру: sudo sh -c 'sleep 300 && systemctl restart ssh' &.

Хардненинг

Параметр	Зачем
`PermitRootLogin no`	не пускать root напрямую
`PasswordAuthentication no`	только ключи (главное против брутфорса)
`MaxAuthTries 3`	меньше попыток за коннект
`AllowUsers alice bob`	белый список пользователей
`AllowGroups sshusers`	белый список групп
`AllowTcpForwarding no`	запретить туннели (если не нужны)
`X11Forwarding no`	отключить проброс X
`ClientAliveInterval 300`	отключать мёртвые сессии

Гибко — через Match (для группы/адреса):

Match Group sftponly
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no

Команды

bash

systemctl status ssh              # состояние сервера
sshd -t                           # проверка sshd_config (синтаксис)
sudo sshd -T                      # эффективная конфигурация (все параметры)
ss -tlnp | grep :22               # слушает ли порт
journalctl -u ssh -f              # логи подключений/отказов
journalctl -u ssh | grep -i fail  # неудачные входы (брутфорс? см. fail2ban)
ssh -v user@host                  # отладка подключения с клиента

Permission denied (publickey)

Права на сервере: ~/.ssh=700, authorized_keys=600, владелец — сам пользователь. journalctl -u ssh → часто «Authentication refused: bad ownership or modes». См. ssh-keys.

Connection refused

Сервер не слушает порт: ss -tlnp | grep :22, systemctl status ssh. Либо порт закрыт файрволом — разреши 22/tcp (см. firewall).

Connection timed out

Сетевой/файрвол-уровень (не дошёл до sshd): маршрут, security group, nftables. Проверь nc -zv host 22.

Сменил порт — не пускает

SELinux/порт не разрешён, файрвол на старом порту, или клиент идёт на 22. Открой новый порт в firewall, проверь sshd -T | grep -i port.

Заблокировал себя сменой конфига

Зайди через консоль гипервизора/serial и откати sshd_config (или sshd -t показал бы ошибку до reload — всегда проверяй).

reload/restart применяют новый конфиг ко всем последующим подключениям сразу; ошибка в PermitRootLogin, AllowUsers или PasswordAuthentication может закрыть доступ, включая твой собственный. Правь конфиг только при открытом втором сеансе и проверяй sshd -t до перезапуска, а не после. Отключение PasswordAuthentication без предварительно установленного и проверенного ключа оставит сервер без единого рабочего способа входа.