SCP через соединение шлюза SSH

Моя схема сети выглядит примерно так:

Теперь Алиса имеет доступ к SSH-шлюзу (теперь это просто шлюз) с:

ssh alice@external.ip

и файл авторизованных ключей на шлюзе выглядит следующим образом

#/home/Alice/.ssh/authorized_keys
command="ssh -t alice@web" ssh-rsa ABCD...E== alice@somehost

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

Вопрос

1. Как я могу настроить это так, чтобы Алиса тоже могла просматривать все на веб-сервере?

2. Я знаю, что это создает отдельное соединение, но есть ли способ, чтобы это работало как обычный ssh, чтобы даже что-то подобное -R12345:localhost:22работало?

Если вы хотите получить доступ к ssh-серверу за другим ssh-сервером, просто используйте «ProxyCommand». Пример: добавить в .ssh / config

Host Alice  
   User myLoginAtAlice # optional 
   ProxyCommand ssh -o Compression=no gateway netcat -w 90 %h %p
   ServerAliveInterval 30
   Compression yes

Host gateway
   HostName gateway.public.ip
   User myLoginAtTheGateway # optional 
   Compression yes

Затем вы можете просто «ssh Alice», «rsync» или «scp» напрямую, используя «Alice» в качестве имени хоста. Магия скрыта для клиента.

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

Объяснение: ssh использует команду, заданную как «команда прокси», в качестве транспорта вместо прямого TCP-соединения. Netcat - это сетевой инструмент, который (среди миллионов других функций) просто перенаправляет свой стандартный ввод / вывод на указанный удаленный хост. Итак, «ssh gateway nc sshserver 22» соединяет вас с ssh-сервером этой машины. % h - это имя хоста, а% p - это порт. Такая настройка позволяет указать «Порт N» для изменения порта без изменения строки ProxyCommand.

Я активирую сжатие на конечном компьютере и отключаю внешнее сжатие, поскольку сжатие зашифрованных или сжатых данных больше не уменьшает объем данных. Любая манипуляция с настройками сжатия также является необязательной.

У меня была точно такая же проблема, как эта, но я заставил ее работать, не меняя ничего радикально

Все, что я сделал, это добавил $ SSH_ORIGINAL_COMMAND к шлюзу authorized_keys, чтобы пройти через все по цепочке к конечному серверу.

Итак, это:

#/home/Alice/.ssh/authorized_keys
command="ssh -t alice@web" ssh-rsa ABCD...E== alice@somehost

становится:

#/home/Alice/.ssh/authorized_keys
command="ssh -q -t alice@web $SSH_ORIGINAL_COMMAND" ssh-rsa ABCD...E== alice@somehost

-Q используется для подавления сообщения о закрытии соединения с компьютера конечной точки, поэтому оно не попадает в локальный вывод при локальном перенаправлении.

Затем вы можете использовать scp следующим образом:

scp localFileName alice@exernal.ip:/path/on/end/point/remoteFileName

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

Например:

ssh -t alice@external.ip "ls -l" > tmp

Это работает, потому что кажется, что sshd заполняет переменную окружения $ SSH_ORIGINAL_COMMAND командой и, указанными клиентом ssh, но я не уверен, почему это чудесным образом позволяет scp проходить через компьютер конечной точки, а также команды.

К сожалению, переадресация портов не поможет копировать файлы напрямую с рабочей станции Алисы на веб-сервер с помощью scp. В этом посте SO я объяснил, почему ssh (и scp, поскольку он использует те же механизмы аутентификации) не будет работать для соединений, переадресованных с помощью ssh.

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