Я хочу делегировать аутентификацию на основе pubkey для данного пользователя другому серверу SSH, не изменяя конфигурацию клиента, но позволяя вносить изменения в программное обеспечение сервера.
Уже есть несколько подобных вопросов. это и этот запрашивать отправку на основе имени хоста, а не имени пользователя. это и этот попробуйте отправить по имени пользователя, но у них есть ответы только там, где первый сеанс ssh вызывает вызов второго ssh , поэтому в конечном пункте назначения будут использоваться только открытые ключи, если включена пересылка агента. Этот вопрос здесь более конкретен в том, как возможно достичь заявленной цели.
я прочел RFC 4251 раздел 1. В соответствии с этим в стеке SSH есть три уровня. Уровень TRANS (транспортный) обеспечивает целостность и аутентификацию сервера. Уровень USERAUTH (аутентификация пользователя) выполняет аутентификацию пользователя, а уровень CONNECT (соединение) мультиплексирует фактические данные полезной нагрузки. Поэтому я бы хотел, чтобы человек находился посередине перехвата на уровне TRANS, при пересылке уровней USERAUTH и CONNECT.
client proxy server
CONNECT X-----------X
USERAUTH X-----------X
TRANS X---X X---X
TCP X---X X---X
Поскольку уровень TRANS выполняет аутентификацию сервера, клиент, очевидно, увидит открытый ключ прокси, что приемлемо в моем приложении. В соответствии с RFC 4252 раздел 1, уровень USERAUTH действительно получает идентификатор сеанса от уровня TRANS. Это означает, что фактическому серверу, вероятно, потребуется некоторая дополнительная функция, чтобы он мог использовать идентификатор сеанса, согласованный между клиентом и прокси, вместо того, который он согласовал сам с прокси.
Это можно сделать?
Есть ли известная реализация такой схемы?
Или есть что-то, что я упустил, почему это не может работать, даже если у вас есть контроль над программным обеспечением, работающим как на прокси, так и на сервере?
Различные сервисы поставляются в виде готовых к использованию образов Docker, которые тем или иным образом предоставляют git через ssh доступ к своим данным. Обычно весь доступ осуществляется с использованием одной учетной записи с использованием открытых ключей для фактического различения пользователей. Поэтому передача открытого ключа жизненно важна.
Эти службы можно предоставлять, используя разные порты. Но использование привилегированных портов для служб, отличных от зарегистрированных, может рассматриваться как плохой стиль, использование непривилегированных портов как угроза безопасности, и в целом имена пользователей гораздо более запоминаются, чем номера портов. Кроме того, в любом случае требуется имя пользователя, даже если это просто git. Отсутствие нестандартного номера порта позволяет использовать более короткий ‹user›@‹host›:‹path› нотация репозиториев git, в отличие от более длинных ssh://‹user›@‹host›:‹port›/‹path›.
Я сомневаюсь, что какие-либо распространенные образы Docker в настоящее время используют что-то подобное. Но если бы это было возможно, можно было бы предложить добавить необходимые серверные изменения к этим изображениям, чтобы подобные подходы стали жизнеспособными в будущем.