У меня в сети есть следующие настройки:
Internet <--> Bastion <--> Local Network
У меня несколько пользователей, и каждый пользователь привязан к определенной машине. Или другими словами: каждый пользователь должен иметь доступ только к одному из этих серверов. Например: Пользователь1 -> Машина1, Пользователь2 -> Машина2 и т. Д.
Эти пользователи будут подключаться извне моей сети, и я рассмотрел много вариантов, как перенаправить их подключения через мой хост-бастион в мою сеть.
В конце концов я выбрал Match Blocks и forcecommand.
Итак, мой / etc / ssh / sshd_config на бастионе выглядит так:
Match User User1
ForceCommand ssh User1@Machine1 $SSH_ORIGINAL_COMMAND
User1 подключается к хосту-бастиону, который автоматически устанавливает соединение с Machine1.
Насколько я понял ForceCommand, User1 не будет иметь реального доступа к хосту-бастиону, потому что все его операции сначала будут обрабатываться блоком сопоставления, следовательно, перенаправляются на Machine1. Однако так ли это на самом деле? Достаточно ли этого для безопасной установки? Пользователь в любом случае находится в тюрьме на Machine1, так что там у него не так много возможностей.
Я использую хост-бастион ProxyCommand и -W отметьте как в этом примере:
ssh -o ProxyCommand='ssh -W %h:%p user@bastion' user@machine
Я использую этот подход из соображений безопасности. Связь между клиентом и целевой машиной зашифрована и проходит сквозную аутентификацию, что означает, что она остается защищенной даже в случае взлома бастиона. Скомпрометированный хост-бастион обеспечит не меньшую безопасность, чем сквозное использование ssh без бастиона.
Это также избавляет от необходимости использовать переадресацию агента. Клиент может использовать аутентификацию на основе ключей сначала для доступа к бастиону, а затем снова для доступа к целевому хосту без предоставления ни одному из них соединения с агентом, которое могло бы использоваться для злоупотребления закрытым ключом, присутствующим на клиенте.
Это также ограничивает код, от которого я зависим от хозяина бастиона. Мне вообще не нужно выполнять какие-либо команды на бастионе. -W подразумевает отсутствие команды, а также переадресацию одного порта, это переадресация портов - все, что нужно разрешить хосту-бастиону.
Имея в виду этот подход, я бы рекомендовал максимально заблокировать хост-бастион, позволяя использовать только команды указанной выше структуры.
В ~/.ssh/authorized_keys файл на бастионе может принадлежать пользователю root (как и все каталоги на пути от корня файловой системы к нему), это снижает риск его изменения, даже если кому-то удалось взломать бастион как непривилегированный пользователь хост.
В authorized_keys права клиента могут быть ограничены с помощью опций command, no-agent-forwarding, no-pty, no-user-rc, no-X11-forwarding, а также использование permitopen чтобы ограничить переадресацию портов, чтобы разрешить доступ только к порту 22 на хосте, к которому этому пользователю разрешен доступ.
В принципе, такой подход будет безопасным, даже если несколько пользователей используют одно имя на бастионе. Но вы получаете немного больше разделения, используя отдельные имена пользователей на бастионе.
Вы можете легко обойти ForceCommand, поскольку он срабатывает при запуске оболочки. По сути, это означает, что сначала обрабатывается ваш rc-файл оболочки, а затем ForceCommand, если вы позволяете ему попасть туда. просто exec sh в вашем файле оболочки rc вызовет другую оболочку и заставит ForceCommand ждать, пока вы не выйдете из этой оболочки.
Итак, нижняя строка; если пользователь может каким-то образом отредактировать свою оболочку rc (скажем .bashrc) через ftp, sftp, scp или каким-либо другим способом, то ForceCommand не является чем-то, на что можно полагаться.
Думаю, в большинстве случаев это нормально, но проблема с безопасностью - это то, о чем никто еще не подумал. Нет никаких гарантий.
Например, долгое время никто не задумывался о том, как можно создавать функции из переменных среды в bash, но недавно люди поняли, что это можно ниспровергнуть, и одним из последствий этого было то, что ForceCommand можно было обойти (на по крайней мере, как реализовано в файле authorized_keys), если оболочка пользователя была bash. Bash исправили, и, надеюсь, ваша версия актуальна, но такие вещи случаются.
Я не совсем уверен, действительно ли определение ForceCommand то же самое, что определение этих команд в файлах authorized_keys. Я не смотрел так внимательно.
Сделать .bashrc принадлежит root:usergrp но все еще может быть прочитан sshd, запущенным от имени пользователя, входящего в систему. Установите perms / owner в $ HOME, запрещая создание новых файлов пользователем. Таким образом, root контролирует содержимое .bashrc , позволяя ему делать то, что ему нужно, но сам пользователь не может изменять эти настройки или разрешения на файлы / каталоги, которые косвенно позволяли бы им изменять содержимое .bashrc.
У меня есть другая идея. Для каждого пользователя на сервере бастиона вы можете определить его оболочку в / etc / passwd как сценарий bash, который просто запускает ssh user1 @ machine1, user2 @ machine2 и т. Д. Таким образом вы убедитесь, что у них нет действительных shell на самом сервере и что они просто подключаются к машине, к которой они должны подключаться.