NB: Os clientes OpenSSH que estou usando estão todos na versão 7.2 , portanto, não RemoteCommand
estão disponíveis.
Suponha a seguinte configuração:
- máquina
foo
é um host de salto e fornece acesso ao hostbar
por meio de seulocalhost:10022
bar
fica dentro de uma rede dentro da qual podemos acessar o hostrdp
e acessar sua porta RDP (3389). Na verdade, dou o IP derdp
dentro das minhas linhas de comando e configuração, mas presumo que seja legítimo usar seu nome, desde que a pesquisa de nome funcione. Por brevidade, estou usandordp
aqui.
O objetivo agora é obter acesso rdp:3389
conectando-se bar
via jump host foo
e encaminhá-lo para localhost:33389
a máquina local da qual estou chamando ssh bar
.
[local:33389] --> {foo} --> {bar} --> [rdp:3389]
Interlúdio
Eu resolvi isso anteriormente com o PuTTY da seguinte maneira:
- crie uma conexão
foo
e configure um encaminhamento local-L 33389:localhost:33389
, vinculando assimlocalhost:33389
a máquina locallocalhost:33389
afoo
. - use o seguinte comando remoto para transportar o encaminhamento de porta para a rede dentro da qual
bar
fica passandossh -L 33389:rdp:3389 -A bar
. Host bar
está configurado para se conectarfoo
e , assim, acessar o host de salto..ssh/config
localhost:10022
bar
A configuração do PuTTY funciona como um encanto, mas depende de um comando remoto para ser executado. Embora um alias de shell seja uma maneira de fazer isso, eu queria saber se há uma maneira de manter tudo dentro do ssh_config(5)
usado pelo meu cliente, usando ProxyCommand
?
Um equivalente aproximado da configuração do PuTTY acima é este:
ssh -L 33389:localhost:33389 foo ssh -t -L 33389:rdp:3389 -p 10022 localhost
ou, desde que Host bar
esteja configurado foo
para passar localhost:10022
por foo
:
ssh -L 33389:localhost:33389 foo ssh -t -L 33389:rdp:3389 bar
E isso parece fazer o trabalho.
Mas é claro que isso é muito para digitar e seria mais fácil poder colocar tudo isso no arquivo de configuração e simplesmente digitar ssh bar
na máquina local.
Conforme RemoteCommand
introduzido no OpenSSH 7.6, isso parece ser bastante trivial:
Host bar
HostName foo
RemoteCommand ssh -L 33389:rdp:3389 -A -p 10022 localhost
LocalForward 33389 localhost:33389
... que deve ser aproximadamente traduzido para a ssh
invocação mostrada acima. Mas, como mencionado anteriormente, estou usando uma versão mais antiga (empacotada) do OpenSSH sem suporte para a RemoteCommand
estrofe.
Aqui está a tentativa que parece mais próxima do que eu quero alcançar.
Host bar
HostName localhost
Port 10022
ProxyCommand ssh -L 33389:localhost:33389 -W %h:%p foo
LocalForward 33389 rdp:3389
A ideia é que na máquina local eu simplesmente invocarei ssh bar
. Na verdade, funciona porque acabo no prompt do shell de bar
, mas o encaminhamento de porta não funciona. Enquanto sudo lsof -i|grep 3389
na máquina local me dá:
ssh 15271 accden 6u IPv6 7933201 0t0 TCP localhost:33389 (LISTEN)
ssh 15271 accden 7u IPv4 7933202 0t0 TCP localhost:33389 (LISTEN)
No host de salto, não vejo nada ouvindo em nenhuma porta contendo arquivos 3389
.
Como ProxyCommand
estabelece a conexão com foo
e estou dando um LocalForward
para a conexão com bar
, espero que funcione.
O que estou fazendo errado?
O objetivo é usar ssh bar
para conectar bar
e ao mesmo tempo rdp:3389
disponibilizar na máquina local como arquivos localhost:33389
. Ajustar os ssh_config(5)
arquivos na máquina local e foo
são permitidos. Passar comandos remotos não é uma resposta válida, no entanto.
Primeiro, com o seu tipo de configuração, o que funcionaria, exigindo de qualquer maneira dois ssh:
O que você realmente precisaria não seria RemoteCommand e sim ProxyJump, simplificando muito sua configuração, com objetivo alcançado apenas com:
Ou a configuração equivalente (apenas):
Com zero porta intermediária necessária.
Infelizmente, o ProxyJump está disponível apenas a partir do openssh 7.3
Mas é facilmente substituído pelo combo
ProxyCommand
/-W
que você estava usando antes.ou como arquivo de configuração:
Ainda existem dois ssh em execução: o oculto é aquele como
ProxyCommand
parâmetro ainda em execução no host local fazendo o link usando um par de pipes com o ssh principal, em vez de uma porta tcp extra. Tentar envolver o host intermediário na participação com o encaminhamento de porta é inseguro ou pode causar conflito (outros usuários de foo podem acessar o túnel ou usar a mesma porta) e sujeito a erros. As extremidades do túnel sempre devem ser mantidas no host do cliente, se possível, onde há controle total. Os túneis intermediários não devem existir ou apontar para o próximo ponto de entrada ssh (esse é o-W
uso aqui).