Eu configurei recentemente uma conexão VPN de casa / trabalho através do cliente openconnect (não sei se isso é importante) e sou capaz de fazer o login nas várias máquinas de gateway no trabalho, mas não consigo scp ou rsync para qualquer coisa que está por trás desses gateways.
Então, posso fazer um ssh gateway e depois, quando estou no servidor, posso executar ssh work_machine . Então, o ssh padrão e interativo funciona.
Em seguida, tentei scp e rsync para o work_machine . Para conseguir isso, eu fiz uma entrada de host de salto no .ssh / config :
Host work_machine
Hostname work_machine_hostname
ProxyJump gateway
User user
No entanto, tentar fazer um scp /local/path/file work_machine:/remote/path apenas trava. Isso acontece com o rsync também.
Alguém tem idéia do que está acontecendo?
UPDATE
Eu também tentei com tunelamento. Fiz um túnel para o gateway , enquanto mantive a configuração do host de salto para o work_machine . Mais uma vez, eu posso ssh no work_machine , mas não consigo scp, nem rsync nele.
Acho que vou voltar ao bom e velho tunelamento até que o resto dos utilitários o acompanhe. É um script extra para configurar as portas na máquina local, mas é confiável.
A propósito, o cliente ssh é o 7.3p1 no Ubuntu 16.10.
UPDATE 2
Totalmente removeu os hosts de salto e retornou ao tunelamento.
Então,
ssh -f -N -L 12345:gateway1:22
ssh -f -N -L 12346:gateway2:22 gateway1
Host tgateway2
Hostname localhost
Port 12346
User user
Agora o último túnel,
ssh -f -N -L 12347:work_machine tgateway2
e
Host twork_machine
Hostname localhost
Port 12347
User user
Essa configuração costumava permitir que eu acessasse o twork_machine diretamente, mesmo que estivesse oculto atrás de duas máquinas de gateway. O scp e o rsync também funcionavam. Agora só ssh interativo, como em ssh twork_machine funciona, mas não scp e rsync. O comando scp simplesmente trava na etapa scp -v -t (da saída detalhada de scp somefile twork_machine: )
Tudo estava bem no lado ssh / scp / rsync das coisas. O que causou um problema foi que o arquivo .login do shell csh que é o padrão no work_machine foi configurado para carregar o bash (via bash -l). Por alguma razão, esta troca de shells confundiu scp e rsync, mas não ssh.