Перечисление SSH и доступ по ключу

LinuxBeginner
Практиковаться сейчас

Введение

Добро пожаловать в этот практический лабораторный практикум, посвященный перечислению SSH и эксплуатации уязвимостей аутентификации по ключу. Secure Shell (SSH) — это фундаментальный протокол для безопасного удаленного администрирования, но неправильные настройки могут создавать значительные уязвимости в безопасности.

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

По завершении вы будете понимать, как:

  • Проверять сетевую связность с помощью ping.
  • Перечислять службу SSH с помощью nmap.
  • Понимать основы аутентификации SSH по ключу.
  • Эксплуатировать слабые разрешения ключей для получения несанкционированного доступа.
  • Навигировать по удаленной системе для поиска конфиденциальной информации.

Приступим.

Проверка подключения к цели с помощью Ping

На этом этапе вы начнете с подтверждения того, что ваша машина может взаимодействовать с целевой системой. Команда ping — это стандартный инструмент сетевой диагностики, который отправляет ICMP-пакеты на хост для проверки его доступности. Это первый и самый базовый шаг в любой сетевой разведке.

Ваша среда включает целевую систему, доступную по имени хоста target.

Выполните следующую команду в терминале, чтобы отправить четыре пакета на target и убедиться, что он в сети:

ping -c 4 target

Вы должны увидеть ответ, похожий на приведенный ниже, подтверждающий, что цель достижима и сетевое соединение стабильно. IP-адрес и время ответа могут незначительно отличаться.

PING target (172.17.0.2) 56(84) bytes of data.
64 bytes from target (172.17.0.2): icmp_seq=1 ttl=64 time=0.091 ms
64 bytes from target (172.17.0.2): icmp_seq=2 ttl=64 time=0.068 ms
64 bytes from target (172.17.0.2): icmp_seq=3 ttl=64 time=0.065 ms
64 bytes from target (172.17.0.2): icmp_seq=4 ttl=64 time=0.067 ms

--- target ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3074ms
rtt min/avg/max/mdev = 0.065/0.072/0.091/0.011 ms

После подтверждения связности вы можете перейти к следующему этапу перечисления.

Сканирование открытых портов с помощью Nmap

На этом этапе вы будете использовать nmap для сканирования целевой системы на предмет открытых портов и идентификации служб, работающих на них. Nmap (Network Mapper) — это критически важный инструмент для специалистов по безопасности, используемый для обнаружения сетей и аудита безопасности.

Мы выполним целевое сканирование порта 22, стандартного порта для SSH, чтобы собрать информацию о версии и ключе хоста.

Выполните следующую команду в вашем терминале:

nmap -sV -p 22 --script ssh-hostkey target
  • -sV: Включает обнаружение служб и версий.
  • -p 22: Указывает, что должен быть просканирован только порт 22.
  • --script ssh-hostkey: Скрипт Nmap Scripting Engine (NSE), который извлекает ключи SSH-хоста цели.

Вывод будет выглядеть примерно так:

Starting Nmap 7.80 ( https://nmap.org ) at 2025-09-19 11:56 CST
Nmap scan report for target (172.17.0.2)
Host is up (0.00020s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.13 (Ubuntu Linux; protocol 2.0)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 0.78 seconds

Сканирование подтверждает, что порт 22/tcp открыт и на нем работает OpenSSH 8.9p1. Эта информация имеет решающее значение для следующего шага, где вы попытаетесь подключиться.

Подключение к цели через SSH

На этом этапе вы будете использовать предоставленный приватный ключ SSH для подключения к цели. Аутентификация по ключу SSH, как правило, более безопасна, чем аутентификация по паролю, но она зависит от того, что приватный ключ хранится в секрете, а разрешения файлов как на клиенте, так и на сервере настроены правильно.

Приватный ключевой файл id_rsa был помещен в ваш каталог ~/project. Чтобы SSH мог использовать приватный ключ, его разрешения должны быть ограниченными. Установите правильные разрешения с помощью команды chmod:

chmod 600 id_rsa

Эта команда гарантирует, что только владелец файла имеет права на чтение и запись, что является требованием для большинства SSH-клиентов.

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

docker exec target-container ls -ld /home/testuser

Если вы видите разрешения типа drwxrwxrwx (777), исправьте их:

docker exec target-container chmod 755 /home/testuser

Теперь используйте приватный ключ для подключения к target от имени пользователя testuser.

ssh -i id_rsa testuser@target
  • -i id_rsa: Указывает файл идентификации (приватный ключ), используемый для аутентификации.

Вам может быть предложено подтвердить подлинность хоста. Введите yes и нажмите Enter.

The authenticity of host 'target (172.17.0.2)' can't be established.
ED25519 key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes

Из-за неправильной конфигурации на сервере (небезопасные разрешения в домашнем каталоге пользователя) служба SSH примет ключ, и вам будет предоставлен доступ без пароля. Вы будете авторизованы и увидите приглашение командной строки цели.

Welcome to Ubuntu 22.04.1 LTS (GNU/Linux 5.15.0-48-generic x86_64)
...
testuser@target:~$

Вы успешно получили доступ к командной строке целевой системы.

Исследование целевой системы и поиск флага

На этом этапе ваша конечная цель — найти и прочитать файл с флагом. Теперь, когда у вас есть доступ к командной строке целевой системы, вы можете исследовать ее файловую систему так же, как и на локальной машине. Это фаза пост-эксплуатации, когда злоумышленник ищет ценные данные.

В настоящее время вы находитесь в домашнем каталоге пользователя testuser (/home/testuser). Используйте команду ls для вывода списка файлов и каталогов в этом месте.

ls

Вы увидите содержимое домашнего каталога, которое должно включать файл с флагом.

testuser@target:~$ ls
flag.txt
testuser@target:~$

Вы нашли flag.txt. Теперь используйте команду cat для отображения его содержимого и раскрытия флага.

cat flag.txt

Терминал выведет значение флага.

testuser@target:~$ cat flag.txt
labex{ssh_k3y_b4s3d_acc3ss_fl4g}
testuser@target:~$

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

Чтобы отключиться от цели, введите exit и нажмите Enter.

Резюме

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

Вы узнали, как:

  • Использовать ping для проверки доступности цели.
  • Применять nmap для детального сканирования SSH-порта, определяя версию службы.
  • Понимать клиентские требования для аутентификации по ключу SSH, включая правильные разрешения для приватного ключа (chmod 600).
  • Использовать уязвимость на стороне сервера, связанную с небезопасными разрешениями файлов, для получения несанкционированного доступа к командной строке.
  • Навигировать по удаленной файловой системе для поиска и извлечения флага.

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