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

Лабораторная: диагностика SSH

В паре со статьёй: Харденинг SSH и аутентификация по ключам

Окружение: одна одноразовая VM или контейнер с установленным openssh-server, и вторая машина (или ваш хост) для подключения. Не выполняйте это против хоста, временная блокировка которого для вас неприемлема.

Начальные условия

  1. Свежая VM с установленным и работающим OpenSSH-сервером (systemctl status sshd / systemctl status ssh показывает active (running)).
  2. Учётная запись не-root пользователя, в которую можно войти по паролю, для настройки.
  3. Доступ к консоли/гипервизору VM независимо от SSH — критично важно: несколько шагов ниже могут заблокировать доступ по SSH, и нужен способ вернуться, не зависящий от самого SSH.

Инструкции

Часть 1 — Сломайте намеренно

  1. Сгенерируйте пару SSH-ключей на клиентской машине и разверните публичный ключ на VM.
  2. Убедитесь, что вход по ключу работает.
  3. Внесите одну из следующих неисправностей (выберите одну, запомните, какую именно):
  4. Неверные права доступа: chmod 644 ~/.ssh/authorized_keys на VM — нет, это уже корректно; вместо этого выполните chmod 777 ~/.ssh (саму директорию) на VM.
  5. Неверная настройка sshd_config: установите PubkeyAuthentication no и перезапустите sshd.
  6. Блокировка файрволом: заблокируйте порт 22 конкретно с IP вашего клиента (не глобально — нужен другой способ исправить, что и есть часть диагностики).
  7. Попробуйте подключиться. Должно провалиться.

Часть 2 — Диагностируйте, не зная ответа заранее

Используйте ssh -v (или -vvv для максимальной детализации) с клиента, и собственные логи сервера (journalctl -u sshd или /var/log/auth.log в зависимости от дистрибутива), чтобы определить:

  1. Клиент вообще доходит до сервера на уровне TCP, или соединение проваливается ещё до попытки аутентификации?
  2. Если доходит до аутентификации, какой метод аутентификации пытается использоваться, и как сервер на него отвечает?
  3. Что конкретно в логе сервера соответствует сбою?

Ожидаемые результаты

  • При неисправности неверные права .ssh: ssh -v покажет, что клиент успешно подключился и предложил ключ, но аутентификация провалилась; лог сервера (не клиента) покажет реальную причину — обычно что-то вроде Authentication refused: bad ownership or modes for directory /home/user/.ssh.
  • При PubkeyAuthentication no: ssh -v покажет, что заявленные сервером поддерживаемые методы аутентификации полностью исключают publickey — видно на стороне клиента, без необходимости смотреть логи сервера.
  • При блокировке файрволом: соединение зависает и в итоге обрывается по таймауту на уровне TCP, до какого-либо обмена баннерами протокола SSH — ssh -v не показывает ничего после "Connecting to \<host>", подтверждая, что это проблема сетевого уровня, не уровня SSH.

Чек-лист диагностики

  • [ ] Проверили ли вы лог сервера, а не только вывод -v клиента? (Обязательно для неисправности с правами — только клиент не показывает, почему ключ отклонён.)
  • [ ] Различили ли вы «connection refused/timed out» (сетевой уровень) и «authentication failed» (уровень SSH, соединение успешно)?
  • [ ] Конкретно для неисправности с правами: какие правильные права для ~/.ssh и ~/.ssh/authorized_keys, и как подтвердить их через stat?

Критерии успеха

Вы завершили эту лабораторную, когда можете с нуля намеренно внести любую из этих трёх неисправностей в VM коллеги и корректно определить — используя только ssh -v и логи сервера — какая именно из трёх это была, не зная заранее.

Очистка / откат

# Восстановить права .ssh, если использовали эту неисправность:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

# Восстановить sshd_config, если меняли:
sudo sed -i 's/^PubkeyAuthentication no/PubkeyAuthentication yes/' /etc/ssh/sshd_config
sudo sshd -t && sudo systemctl restart sshd

# Удалить любое добавленное правило файрвола для теста

Убедитесь, что ssh -v снова успешно проходит с Authentication succeeded (publickey), прежде чем считать лабораторное окружение восстановленным.