Vários túneis SSH (encaminhamento local e remoto) sobre uma conexão mestre OpenSSH? Boa ideia?

Question

A pergunta Usando um canal SSH já estabelecido tem uma resposta que me intrigou. Isso sugere que posso reutilizar uma conexão SSH existente. No entanto, depois de ler mais, vejo que essa solução pode não funcionar no meu caso (vários túneis ao mesmo tempo).

Estou usando o OpenSSH_5.9p1 Debian-5ubuntu1.1, o OpenSSL 1.0.1 14 Mar 2012 (no Kubuntu 12.04).

Aqui está o que estou fazendo atualmente em um script bash:

echo "establishing SSH tunnel for SFTP && opening Dolpin with SFTP connection to remote computer..."
ssh -i "$ID_RSA" "$MIDDLEMAN_USER@$MIDDLEMAN_SERVER" -fL $PORT_NUMBER:localhost:$PORT_NUMBER sleep 20; dolphin sftp://HostSftp:$PORT_NUMBER &

echo "establishing SSH tunnel for VNC && connecting to VNC server for remote desktop support..."
sudo ssh -fL 5901:localhost:$VNC_PORT_NUMBER -i "$ID_RSA" "$MIDDLEMAN_USER@$MIDDLEMAN_SERVER" sleep 20; vncviewer localhost:5901

Minhas preocupações (por que acho que isso pode não funcionar para mim) incluem coisas como esta:

A negative to this is that some uses of ssh may fail to work with your multiplexed connection. Most notably commands which use tunneling like git, svn or rsync, or forwarding a port. Source

e isso:

If you use LocalForward or RemoteForward in your configuration file, you might run into a subtle problem. ... SSH1 (but not OpenSSH) provides a solution. Source

Estou procurando esclarecimentos e instruções:

1. Posso estabelecer os dois túneis acima com uma conexão principal?
2. Isso será tão confiável quanto estabelecer conexões separadas?
3. Se sim para ambos acima, como faço isso?

Obrigado

    

Answer 1

O uso de uma conexão mestre não altera a maneira como você chama o ssh, exceto as opções relacionadas ao compartilhamento de conexão ( -S , -M , -o ControlXXX ). Todas as mudanças de conexão mestre são que, quando uma conexão principal já está estabelecida, novas conexões escravas passam por isso, em vez de autenticar novamente. Isso economiza a necessidade de fornecer uma senha ou chave e pode acelerar notavelmente o estabelecimento da nova conexão.

A multiplexação não faz diferença para os aplicativos. Faz diferença para os firewalls: existe uma única conexão em vez de muitos.

Eu não sei por que Symkat afirma que “o ssh pode não funcionar com sua conexão multiplexada. Mais notavelmente comandos que usam tunelamento como git, svn ou rsync, ou encaminhando uma porta. ” Se funcionou sem multiplexação, também funcionará com multiplexação, porque os aplicativos não podem dizer a diferença.

O Guia Definitivo do SSH não está se referindo à multiplexação de conexão, mas a “Us [ing] LocalForward ou RemoteForward no seu arquivo de configuração”. (Esse livro data de antes da multiplexação de conexão existir.) Está dizendo que você pode estabelecer um túnel escutando em uma determinada porta apenas uma vez. Trata-se de encaminhamento, não de multiplexação.

Para começar a usar a multiplexação, adicione as seguintes linhas ao seu ~/.ssh/config :

ControlMaster auto
ControlPath ~/.ssh/%l_%h_%p_%r.multiplex

Isso é tudo. Se você quiser estabelecer uma conexão com um host e mantê-lo até ser explicitamente eliminado, execute ssh -N destination & . Quando você não quiser mais essa conexão principal, mate o cliente. Você ainda precisará configurar seus túneis exatamente como antes.

Se você estiver usando um host como retransmissora para muitas coisas, convém configurar um proxy SOCKS . Execute ssh -D 1234 destination e informe seus aplicativos com suporte ao SOCKS para usar o proxy SOCKS em localhost:1234 . Claro que isso só funciona com aplicativos que entendem o SOCKS; você pode usar tsocks nas conexões de rede da maioria dos aplicativos que não usam o SOCKS para passar pelo proxy SOCKS (o tsocks funciona redirecionando as chamadas da biblioteca para funções wrapper).