Um
túnel SSH pode ser muito útil em muitos casos, principalmente quando a necessidade não justifica sacar ferramentas mais sofisticadas de criação de túnel ou tampouco a criação de uma VPN.
Como ilustração, pode-se citar três cenários reais de uso, sendo que eu mesmo os uso com extrema frequência. Um deles todo o dia.
Primeiro cenário:
Este não é um cenário que eu uso, mas sim que um conhecido meu usa. Na rede dele tem um servidor de banco de dados MYSQL. Na verdade este serviço encontra-se em execução na mesma máquina onde se encontra o serviço de HTTP e de SSH. A porta na qual o serviço MYSQL escuta é a 3306/TCP.
Evidente que por questões óbvias de segurança, o firewall iptables deste servidor HTTP/SSH/MYSQL não aceita conexões na porta 3306, até porque, como mencionado, apenas a própria máquina usa o banco de dados.
Frequentemente, porém, se desenvolve aplicações em casa, ou em outro lugar que não fisicamente no servidor, e estas aplicações precisam, mesmo que por teste, acessar o banco de dados do servidor.
O que se pode fazer?
Uma saída seria liberar temporariamente a porta 3306 para o máquina cliente quando estiver fazendo testes, mas isto traz sérios problemas de segurança, além de ser não muito prático. Abrir uma VPN com o servidor nem sempre se justifica, pois só se quer realmente acessar o MYSQL por tempo limitado.
Então, pode-se tranquilamente sacar o ssh em seu modo túnel apontando-a para o servidor. Supondo que o IP do servidor seja 10.1.2.3, o seguinte comando executado no cliente resolve:
ssh -TL 33060:localhost:3306 [email protected]
Agora basta apontar as ferramentas locais que usam o BD para o servidor localhost na porta 33060 (se colocou um zero a mais, pois a máquina local poderia ter também o seu próprio BD).
Segundo cenário:
Na faculdade que administro os equipamentos de rede, como switches, tem ips privados. Assim não tem como chegar neles através da Internet. A partir dos consoles da sala de administração, existe rotas que permitem acessar, por exemplo, o switch 192.168.34.100, seja até mesmo por sua interface gráfica sobre HTTP.
Porém, algumas vezes, estou em minha casa e preciso realizar uma pequena manutenção em um dos switches. Novamente, poderia criar uma VPN, mas quero uma solução mais imediata. Então, saco novamente o ssh em modo túnel e digito na linha de comando:
ssh -TL 8080:192.168.34.100:80 [email protected]
Feito isto, apenas abro um navegador e acesso a URL http://localhost:8080. Como já demonstrado nas seções anteriores, todos os pacotes que entrarem na porta 8080 do meu notebook, sairão cifrados de minha máquina, viajando rumo a porta 22 do servidor IPdoMeuConsole, sendo que chegando lá, o ssh decifra os dados e os repassa ao IP 192.168.34.100 na porta 80, sem criptografia.
Terceiro cenário:
Este eu realmente uso todos os dias a anos. Meu notebook tem seu próprio servidor SMTP. Um Postfix instalado para realizar relay em um IP inexistente, algo como 10.2.3.4 que não existe em nenhuma das redes que conheço. Assim, meu servidor SMTP/Postfix ficaria sem poder repassar os emails. Digo ficaria, pois tenho alguns truques na manga.
O conforto de ter um servidor SMTP no meu próprio notebook é que posso eu mesmo criar meus aliases de emails ou mesmo listas. Uso isto diariamente para enviar as notas dos alunos, durante o período letivo. Posso gerar os emails mesmo sem acesso a Internet, pois eles ficam na fila de espera do Postfix.
Porém, quando tenho acesso a Internet, saco o par iptables + ssh para fazer a mágica acontecer. Uso como relay um servidor que gerencio, que é MX do meu domínio. Claro, ele não aceita relay, evidentemente, a menos que seja de um ip autorizado. Tipo, conexões vindas dele mesmo, localhost.
Então eu abro um túnel SSH para este meu servidor:
ssh -TL 2525:localhost:25 [email protected]
Agora todo o pacote jogado na porta local 2525, viajará cifrado até meu servidor e lá será enviado a porta 25 de localhost. Haverá aceitação de relay, pois para o servidor Postfix do MeuServidor o acesso por feito por ela mesmo!
Feito este túnel, eu agora insiro uma regra iptables desviando o tráfego que tentar sair pela porta 25 para a 2525 local, ou seja, quando o Postfix do meu notebook tentar entregar os emails para o falso IP 10.2.3.4 na porta 25, o iptables o irá pegar e jogar na porta 2525 local, que é a entrada do túnel.
Uso tanto isto que até fiz um script que coloca tudo no ar até com uma telinha de status. Caso seja do interesse de alguns, deixo este script como anexo.