SSH Forwarding

Uma das funções  freqüentemente negligenciadas do protocolo SSH é o encaminhamento (ou forwarding ou ainda tunelamento) de conexões.
Exemplos de uso:
  • Administração remota de serviços que só permitem acesso através do endereço localhost (127.0.0.1). Dois serviços com esse comportamento por padrão são o Webmin e o CUPS. (redirecionamento local -> remoto)
  • Acesso seguro a serviços que normalmente não suportam criptografia, como o VNC (redirecionamento remoto-> local).
  • Acesso seguro (criptografado) a emails e sites através de redes públicas e não criptografadas. (redirecionamento local -> remoto)
  • Permitir o acesso de máquinas remotas à sua rede. (redirecionamento remoto-> local)
  • Exibir a tela de um programa gráfico em outra estação. (redirecionamento X11)

Caso 1: Redirecionamento local -> remoto

Nesse caso, vamos especificar uma porta TCP local (na máquina onde é executado o cliente ssh). Todo o tráfego que atingir essa porta será encaminhado pelo túnel SSH para um endereço na rede remota. Esse endereço pode ser a própria máquina onde roda o servidor SSH ou outra, desde que acessível pelo servidor SSH. A porta local precisa estar disponível. Para fechar o túnel, encerra-se a conexão.

A sintaxe do comando SSH para esse caso é:


ssh -L [endereço local]:porta local:host remoto:porta remota servidor_ssh

Onde:
Endereço Local: Endereço IP que será associado a essa conexão. Esse parâmetro é opcional. Se for omitido, a conexão será criada em todos os endereços/interfaces de rede do computador. Se for informado um endereço IP diferente de 127.0.0.1 (ou localhost), outras máquinas poderão utilizar-se do túnel. Caso  seja informado o endereço 127.0.0.1 o túnel ficará disponível apenas para a própria máquina cliente.
Porta Local: Porta TCP que receberá as conexões na máquina cliente e as encaminhará para a máquina remota. Esta porta precisa estar disponível.
Host Remoto: Endereço na rede do servidor SSH  para onde as requisições serão encaminhadas.
Porta Remota: Porta no Host Remoto para onde as conexões serão encaminhadas.
Servidor SSH: Endereço ou nome do servidor SSH que receberá as conexões.
Obs: outros parâmetros (como nome de usuário, porta SSH, etc) podem ser informados normalmente.

Exemplos:
acessando remotamente a administração de impressoras do CUPS (porta 631):
Vamos direcionar o trafego na porta local 5555 para a porta 631 do servidor 192.168.0.12, através de uma conexão SSH nesse mesmo servidor:

ssh -L 5555:192.168.0.12:631 192.168.0.12

Caso fosse necessário utilizar um usuário específico (por exemplo: joao), o comando ficaria assim:

ssh -L 5555:192.168.0.12:631 joao@192.168.0.12

Caso o servidor SSH estivesse em uma porta diferente da padrão (22), digamos porta 2222, faríamos dessa maneira:

ssh -p 2222 -L 5555:192.168.0.12:631 joao@192.168.0.12

Caso você deseje que as máquinas que se conectarem à sua estação possam utilizar o tunel, o comando seria (supondo que o IP de sua estação seja 10.0.0.28):
ssh -p 2222 -L 10.0.0.28:5555:192.168.0.12:631 joao@192.168.0.12

Com a conexão estabelecia, bastaria abrir o navegador web e acessar o endereço
http://localhost:631 (ou http://10.0.0.28:631 no caso de outras máquinas) para realizar o acesso.

Outro exemplo prático: Suponhamos que você está com seu notebook em um CyberCafe, com conexão WiFi Open (sem criptografia) e deseja acessar os emails no servidor POP de sua empresa de forma segura. Para isso, você precisaria ter acesso SSH a um dos equipamentos da empresa, como um firewall ou outro servidor. Supondo-se que que dados de conexão sejam:
Firewall (com acesso SSH na porta 7788): 200.200.200.200
Servidor de Email (rodando POP na porta 110) : 172.16.100.50
Usuário para acesso SSH: antonio

o comando seria: 

ssh -p 7788 -L 110:172.16.100.50: antonio@200.200.200.200

Agora, basta configurar seu cliente de email para acessar o servidor POP-3 no endereço 127.0.0.1, porta 110 e acessar suas mensagens de forma criptografada.

Caso 2: Redirecionamento remoto -> local
Esse redirecionamento é pouco usado, mas mesmo assim bastante útil. Já o utilizei algumas vezes da seguinte maneira: na empresa onde trabalhava, eu administrava algumas máquinas que ficavam dentro da rede dos clientes. Essas máquinas normalmente não tinham acesso à internet, e o processo de liberação de internet para esses equipamentos era muito burocrático, o que causava problemas na hora de fazer alguma atualização ou instalar novos programas. Minha solução foi utilizar um redirecionamento SSH remoto, permitindo que os equipamentos utilizassem o proxy da minha empresa, e saíssem para a internet através do meu link. Em um caso como esse, o comando ficaria assim:

ssh -R 3128:192.168.0.210:8080 juca@200.200.200.200

No exemplo acima, eu conectei com o usuário juca no servidor 200.200.200.200. Após conectar, basta configurar o programa para utilizar um proxy no endereço localhost, porta 3128. Tudo que a máquina remota "jogar" nesta porta será redirecionado para a porta 8080 do IP 192.168.0.210 na minha rede local.

Caso 3: Redirecionamento do X Server (X11 Forwarding)

Esse é um dos mais simples, e ao mesmo tempo mais úteis: é possível "puxar" a tela de um programa de outro servidor Linux. Nesse caso, o programa estará rodando na máquina remota e apenas as informações de mouse, teclado e tela são trafegadas via rede. É semelhante ao próprio protocolo SSH (onde é realizado um acesso a uma máquina remota, e todo o processamento ocorre na máquina acessada. Nossa máquina apenas envia e recebe informações de teclado e tela). A diferença nesse caso é que como é utilizado o protocolo X, as informações de tela são gráficas, ao invés de apenas texto. Para utilizar o redirecionamento, simplesmente abra um terminal modo texto (já dentro do ambiente gráfico) e digite:

ssh -X usuario@192.168.0.1

A opção -X faz toda a mágica para você. Agora basta rodar qualquer aplicativo gráfico, e embora a tela apareça no seu computador, todo o processamento ocorrerá na máquina remota. O aplicativo também estará acessando o hardware (discos, fitas, etc) da máquina remota. Isso é utilizado para acessar consoles de administração remota, para tarefas que seriam muito complexas (ou mesmo inviáveis) em linha de comando. Mais simples impossível!

Nenhum comentário: