В AWS управление доступом через ssh proxy + sshd

Question

В AWS наши пользователи (системные администраторы) могут обращаться к серверам внутренней зоны БД, используя SSH-туннелирование без ограничений локального firwall. Как вы знаете, для доступа к внутреннему узлу пользователь должен сначала пройти через сервер шлюза общей зоны. Поскольку шлюз на самом деле является проходом, я хочу контролировать трафик от туннелированных пользователей на сервере шлюза. Например, чтобы получить подключенные в настоящее время IP-адреса всех клиентов, чтобы определить внутренний путь (например, сервер DB-сервера), пользователь, к которому я обратился дальше, хочу контролировать подключение неавторизованных пользователей.

К моим мечтам сбываются, я думаю, что идея ниже идеальна. 1) Измените порт sshd на что-то иное, чем 22. Перезапустите демон sshd. 2) Найдите ssh-прокси (nginx, haproxy или еще) до sshd и позвольте прокси-серверу получить весь трафик ssh от клиентов. 3) Прокси-сервер ssh трассирует трафик на sshd 4) Затем я могу видеть всю активность пользователя, анализируя протокол ssh proxy. Вот и все.

Возможно ли мечтать?

Answer 1

Умный, но с критическим недостатком: вы не получите никакой новой информации.

Почему? Первый S в SSH: «безопасный».

«Прокси-сервер ssh», который вы планируете, не сможет рассказать вам ничего о том, что происходит внутри соединений SSH, в котором обсуждаются туннели. Разумеется, соединения зашифрованы, и значительная точка SSH заключается в том, что ее нельзя обнюхивать. Тот факт, что прокси-сервер ssh находится на одной машине, не имеет значения. Если бы его можно было обнюхать, это было бы небезопасно.

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

В реальности это не будет «прокси-сервер ssh» - это был бы наивный прокси-сервер TCP-соединения во входящем соединении.

Таким образом, вы не сможете узнать какую-либо новую информацию при таком подходе.

Это похоже на то, что вам нужно для вашего демона ssh, предположительно openssh, для регистрации соединений туннеля, установленных подключающимися пользователями.

This blog post (который вы, как ни странно, нужно обойти недействительный сертификат SSL для просмотра) был упомянут at Server Fault и показывает, что, как представляется, простой модификации к исходному OpenSSH код для входа информацию вы хотите: кто настраивал вверх по туннелю и тому месту.

Or, enable some debug-level logging on sshd.

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