Как вы уже читали в заголовке, в настоящее время я использую несколько контейнеров докеров, которые используются в качестве серверов git и обычно должны работать под портом 22. Очевидно, это не работает, но мои запросы будут следующими.
На порту 22 должно быть доступно следующее:
Я знаю, что мне пришлось бы синхронизировать ключи ssh между контейнерами и учетными записями, но это не было бы большой проблемой, но у меня нет идеи, можно ли создать систему перенаправления.
Один из моих подходов - использовать ForceCommand но я не смогу перенаправить используемый ключ SSH ...
Еще одна идея - запустить небольшой инструмент на 22-м порту, который просто маршрутизирует полные запросы между всеми демонами SSH, но я (пока?) Не нашел такого инструмента и не знаю, можно ли создать такой инструмент. по соображениям безопасности.
Я не думаю, что вам действительно нужно «перенаправлять используемый ключ ssh», вы можете создать ключ / сертификат для каждого пользователя, у которого есть свой ключ как authorized_keys, а затем вы можете использовать ssh -i $key $final_destination
через ForceCommand.
Если бы вы использовали AuthorizedKeysCommand
вы можете запросить центральный репозиторий открытых ключей, это может вернуть 2 строки - одну для публичного ssh-ключа реальных пользователей и вторую для «внутреннего публичного ssh-ключа», вы можете различить эти две строки с комментарием и запросить этот репозиторий для ключ на основе информации, с какого хоста вы делаете запрос. Например. на хосте перехода вы можете фильтровать открытый ключ, который, например, имеет этот комментарий 'foouser @', в конечном пункте назначения вы можете, наоборот, запросить открытый ключ чужого с комментарием '@internal'. С недавним OpenSSH вы могли использовать узел перехода ExposeAuthInfo
sshd, чтобы узнать, какой открытый ключ ssh использовался для входа в узел перехода, тогда вы можете повторно запросить ключи в центральном репозитории и grep, который соответствует одному в $ SSH_USER_AUTH. Этот способ будет знать на основе возвращенной строки с открытым ключом ssh и комментировать, какой закрытый ключ использовать для выполнения ssh до конечного пункта назначения.
Пользователю все равно, как он вошел в конечный хост, особенно если это не интерактивная оболочка.
AuthorizedKeysCommand на jumphost и конечном пункте назначения:
#!/bin/sh
user=$1 # git !
filter=$2 # @$
cat /home/git/.ssh/authorized_keys 2>/dev/null | grep "${filter:-@$}"
exit 0
sshd_config на хосте перехода:
ExposeAuthInfo yes
Match User git
AuthorizedKeysCommand /path/to/authorizedkeyscommand git # @$ as default
ForceCommand /path/to/forcecommand git
AuthorizedKeysCommand может возвращать:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILleQxrxxxxxxxxxxxxxxxxxxx foouser@
ForceCommand на хосте прыжка:
#!/bin/ksh
set -x
user=$1 # git
if [[ -r ${SSH_USER_AUTH} ]]; then
pubkey="$(cat ${SSH_USER_AUTH} | cut -d' ' -f2-)"
realuser=$(/path/to/authorizedkeyscommand git | grep "${pubkey}" | sed 's/^.* \([^@]*\)@$/\1/' )
[[ -n ${realuser} ]] && exec ssh -i $HOME/${realuser}_key <final_destination> "${SSH_ORIGINAL_COMMAND:-}"
else
exit 1
fi
Что-то вроде этого...