O cenário é o seguinte, você precisa acessar centenas ou mesmo milhares de servidores diferentes, e executar o mesmo comando via SSH.

Ah, e o uso de chaves não é possível.

Ah, e você tem diferentes senhas de diferentes complexidades nestes hosts.

Ah, e muitas dessas senhas estão expiradas e precisam ser trocadas antes de tudo.

Ah, e você precisa também executar comandos como root.

Ah, e você também tem diferentes senhas de root nestes hosts (sudo não é uma opção).

Ah, e você precisa também fazer scp de arquivos para esses hosts.

O que fazer? Chamar o estagiário? NÃO! Você usa o E4SSH Ele é um script tosco feito para contornar essas situações, fazendo o trabalho repetitivo das tarefas supracitadas.

Se você tem horror a código macarronês, pare por aqui, enquanto você ainda não foi ferido.

A única coisa chata mesmo é que eu tinha feito vários bugfixes nele e perdi essa versão mais atualizada. E como não devo voltar a mexer nesse script, fica por isso mesmo.
Se você realmente pretender usar isso, leia bem o código antes.
e4ssh.py – Download aqui

Para guardar para a posteridade, estou disponibilizando o PDF da Easy Linux 09 com a minha matéria sobre jogos no Linux. Hoje em dia a informação está bem desatualizada, mas… Pode ser útil eventualmente! Aproveito para agradecer ao Cav3ira da Linux Brasil, que mantém vivo uma cópia do artigo publicado em meu antigo blog, antes de que eu perdesse todos os dados com a maldita DreamHost. N’joy!

E aqui o link para baixar o vídeo.

Ah, os túneis. Mistura de dádiva e maldição para os usuários fuçadores e administradores de rede, respectivamente. Neste artigo irei abordar como utiliza-los para burlar quase qualquer tipo de restrição imposta ao acesso a internet em redes públicas; que podem não só serem utilizados para fins excusos ou para a defesa da liberdade de expressão na China ou em Cuba, mas também para simplificar muito o seu dia-a-dia.

Antes de começar:
Todos os métodos que irei comentar aqui assumem que você tenha disponível uma outra conexão à internet disponível em algum lugar, seja em sua casa ou em um servidor pago ou de terceiros, para que seja usado como proxy. Nerd que se preze sempre tem a mão uma conexão SSH disponível

Se você não tem uma, suas opções para conseguir uma são:

• Registrar-se em um servidor gratuito – Geralmente os serviços de shell gratuitos são bem limitados, mas você pode tentar o Cjb.net ou o Rootshell.be, ou ainda caçar algum outro.
• Largar a mão de ser muquirana e usar um serviço comercial: Boa parte dos provedores de hospedagem costumam prover também serviços de SSH, com toda a qualidade e customização que o seu dinheiro pode comprar – E nem costuma ser tão caro assim. Minha dicas: VPSByte para VPSs (Virtual Private Server) a partir de US$10/mês, ou o LeaseWeb para um serviço mais sofisticado, com servidor dedicado como o que a Chita usa
• Instalar seu próprio servidor na conexão de casa – Algo que pode ser feito com o seu desktop ou mesmo ou instalando Linux no seu roteador para não precisar deixar o micro ligado 24/7.

Método 1 – O Clássico Tunelamento SSH

Local: Praticamente qualquer rede corporativa ou pública (lan houses, escolas, faculdades)
Problema: Você consegue acesso normal a HTTP, contudo a navegação é barrada para alguns sites específicos, devido ao firewall draconiano. Além disso, toda sua navegação está sendo logada no servidor da instituição – Um prato cheio para qualquer amante de teoria da conspiração. Você não consegue acessar portas não-HTTP, o que impede o uso de alguns programas.
Solução: O clássico tunelamento SSH irá criar um canal de comunicação privativo entre o seu desktop e seu servidor, cujo conteúdo não poderá ser interceptado pela rede pública do mal, graças a criptografia empregada. Dependendo do caso, sua navegação poderá até mesmo ficar mais rápida do que seria normalmente, se utilizar também a opção de compressão SSH!

Como fazer:
Para isso, você irá precisar que a rede permita uma conexão TCP (SSH) até o seu servidor. Como em geral nessas redes são permitidas apenas conexões TCP para serviços HTTP, (porta 80 ou 443), é recomendável que o seu servidor pessoal fique ouvindo SSH também nessas portas, além da padrão 22. Desta forma você poderá se conectar a ele “disfarçado” de requisição HTTP/S.

1) Abra uma conexão ssh até seu servidor, com as seguintes opções:

ssh usuario@seuservidor.seudominio.com -D 8080 -C

A opção -D indica que deverá ser criada uma Tunel Dinâmico na porta 8080 de seu desktop. Um túnel dinâmico funciona exatamente da mesma forma que um proxy SOCKS, ou seja, você pode pode configurar qualquer aplicação que tenha suporte a SOCKS para que utilize o túnel!

A opção -C indica que deverá ser utilizada compactação de dados na conexão. Utilize-a somente se a conexão entre os dois pontos (Seu Desktop e seu Servidor) não for muito rápida.

Se você usa Putty/Windows (Meus pesames pela segunda opção), a opção equivalente a -D se encontra em Connection, SSH, Tunnels e a -C em Connection, SSH.

2) Configure seu navegador para utilizar o túnel:

No Firefox, basta você ir em Editar, Preferências, Rede, Conexão – Configurar, Configuração de manual de proxy, e no campo SOCKS, informe localhost e porta 8080.

2b) Somente para Linux Users -> Use a força o tsocks!

Visto que nem todas as aplicações tem suporte a proxies, você pode se deparar com um caso onde você não pode conseguir tunelar o seu tráfego. Certo? ERRADO! Ao menos se você usa Linux

Para isso existe o tsocks. Ele é uma biblioteca para o uso transparente de proxy socks. Basta que você execute qualquer aplicação com ele e voilá! Todo o tráfego daquela aplicação será redirecionada para o seu proxy, sem necessidade de configuração ou mesmo suporte da aplicação para proxy socks.

3) Teste que a aplicação está realmente usando o túnel

Uma forma de fazer isso é acessar http://tools.chita.com.br – O IP e Hostname de seu servidor deverão ser exibidos, e não os da rede que você se encontra.

Método 2 – Tunelamento HTTP

Se a sua rede for realmente restritiva e não permitir nenhuma conexão externa a não ser por um proxy HTTP, não tema! Você ainda tem chances!

Método 2A – Tunelamento HTTP+SSH

Esta solução é bem parecida com a do método 1, com a única diferença de que você irá realizar uma conexão SSH passando pelo Proxy HTTP, e não diretamente.

Se você usa o Putty, basta configurar o endereço do Proxy diretamente em Connection, Proxy:

Com o bom e velho ssh de linha de comando, você irá precisar da opção ProxyCommand. Essa opção é bem interessante, porque permite a possibilidade de utilizar qualquer outro programa para estabelecer o tunel no qual a sessão SSH será estabelecida. Neste exemplo, iremos usar o netcat como ProxyCommand. Resumindo, o netcat vai ser responsavel por realizar a conedxão de sua máquina ao proxy, e a partir deste ponto o SSH assume, usando esta ponte para abrir a sessão SSH normalmente.

Edite o arquivo ~/.ssh/config

Adicione as linhas:

## Para todos os hosts,
Host *
ProxyCommand connect -H proxy.local.net:8080 %h %p

Este método exige que o Proxy permita o uso de SSL (Comando Connect). Se não for o seu caso, leia o próximo método.

Método 2B – Tunelamento HTTP Puro

No caso de um proxy HTTP REALMENTE restritivo, onde SSL não possa ser usado, ainda existe mais um jeitinho: Tunelar por HTTP Puro.
A ferramenta clássica para este fim é o GNU httptunnel. Ele é dividido em 2 partes: cliente (htc) e servidor (hts).
O processo todo é bem simples, basta você especificar no cliente qual será a porta local a ser redirecionada e no servidor qual será a porta destino. Exemplo:

Cliente:

htc -F 12345 192.168.1.100:443

Servidor:

hts -F 443 ssh.meuservidor.com:22

Desta forma quando você realizar uma conexão em seu desktop, localhost na porta 12345, o cliente htc irá encaminhar o tráfego encapsulado em HTTP para o servidor 192.168.1.100:443, que irá estar executando o hts. O hts, por sua vez irá desencapsular o tráfego recebido e encaminha-lo para ssh.meuservidor.com:22.
Na prática, isso permite que você possa usar SSH e o tunelamento clássico que mencionamos no método 1, mesmo que o seu proxy de regime comunista não permita tal ato, uma vez que todo o tráfego será convertido em HTTP Puro, amado e geralmente permitido sem ou com poucas restrições pela maioria dos administradores de rede.

O GNU httptunnel, contudo, tem algumas limitações chatas:

• A parte server hts toma a porta de entrada só para ela e não pode compartilha-la com um webserver. Isso é extremamente incoveniente, visto que conseguir um servidor com uma porta privilegiada 80 ou 443 dando sopa é quase sempre um ato homérico.
• Se você ter destinos diferentes, irá ter que rodar diversas instancias do servidor, cada uma com seu destino e porta de entrada respectivos. Não é um problema se você pretende tunelar apenas uma conexão SSH para método clássico, mas com certeza será um problemas se você quiser tunelar diretamente tráfego sem depender do SSH.

Por sorte, acabei encontrando um programa que se propõe a corrigir esses erros terríveis do httptunnel, o webtunnel.

O funcionamento é bem parecido com o do httptunnel, com a grande diferença que a parte servidor roda dentro de um webserver, logo, não toma uma porta importante como a 80 ou 443 só para si, podendo ser hospedado em praticamente qualquer webhost existente. O destino da conexão é especificado na parte do cliente e não da do servidor, permitindo que sejam criados diversos destinos diferentes de uma forma bem simples e tão prática que pode até mesmo dispensar o uso do SSH, dependendo de sua necessidade.

Exemplo:

Servidor:
Basta publicar o arquivo wts.pl em qualquer parte visível de um website que tenha suporte a perl.

Cliente:

./wtc.pl tcp://localhost:12345 tcp://ssh.meudominio.com:22 http://meuservidorweb.com/wts.pl

Neste exemplo, todo o tráfego chegando a localhost na porta 12345 será redirecionado para ssh.meudominio.com na porta 22, usando http://meuservidorweb.com/wts.pl como túnel. Apesar de logico, vale lembrar que o destino será sempre o como é visto pelo servidor e não pelo cliente.

Estou disponibilizando a parte servidor aqui na Chita, para voces brincarem: http://tools.chita.com.br/wts.pl

Fique a vontade para usa-lo para um eventual acesso, mas no caso de abuso, serei obrigado a retira-lo do ar.

De qualquer forma, com este túnel aberto, basta você abrir uma sessão de SSH para a porta especificada e usar o Método 1 para não precisar criar diversos destinos diferentes durante a navegação:

ssh usuario@localhost -p 12345 -D 8080 -C

Métodos mais obscuros:

Se nenhum dos métodos de tunelamento acima funcionaram ou se aplicam a você, chegou a hora de tentar usar alguns métodos mais obscuros, maquiavélicos e perversos.

CUIDADO: O uso inescrupuloso dos métodos abaixo pode fazer com que você passe o resto da eternidade queimando nos mármores do inferno. Você foi avisado.

Local: Hotspots pagos em geral (Aeroportos, Cafés, etc), Dial up 0800 que alguns provedores oferecem para a assinatura do serviço (Lembra dos CDs da AOL?)  ou redes administradas diretamente por algum ditador comunista.

Problema: Você precisa urgentemente de acesso a internet. Não querem que você tenha acesso a internet enquanto você não abra a sua carteira ou aceite que o regime vermelho é futuro da nação.

Soluções:

Estas soluções consistem no princípio que quando sua conexão deveria estar bloqueada, como acontece quando você está conectado em um hotspot e tem acesso somente a página de boas-vindas da operadora ou para a compra de crédito, sua conexão não costuma estar completamente bloqueada. Na grande maioria dos casos apenas conexões TCP estão bloqueadas, que é o que pessoas comuns e mentalmente saudáveis usam para navegação. Você, por outro lado, pode se aproveitar de que outros tipos de tráfego costumam ser “esquecidos” de ser bloqueados pelos administradores, como UDP, ICMP e DNS – E sim, você também pode usa-los para navegar com os métodos abaixo:

Método 3: OpenVPN Server na UDP 53.
Possívelmente a solução mais simples possível.
Em geral essas redes não restrigem tráfego UDP, principalmente na porta 53, geralmente utilizada para servidores de nomes. Você pode muito bem rodar a OpenVPN em seu servidor, fazendo com que ele ouça na porta 53 UDP – E conseguir conectar a VPN sem grandes problemas a partir dessas redes.
Para verificar se tal façanha é possível, basta verificar se você consegue se comunicar com um servidor de DNS Externo ao da rede que voc6e se encontra. Por exemplo:

nslookup www.uol.com.br – 208.67.220.220
Server:         208.67.220.220
Address:        208.67.220.220#53

Non-authoritative answer:
Name:   www.uol.com.br
Address: 200.221.2.45
Name:   www.uol.com.br
Address: 200.98.249.12

Neste exemplo, a partir de minha rede, me comuniquei diretamente com o servidor de DNS 208.68.220.220 (da OpenDNS) por UDP 53, e tive sucesso na resolução de nome. Significa que a comunicação UDP/53 está liberada e eu poderia me conectar normalmente através do OpenVPN.

Contudo, se a saída for como essa:

nslookup www.uol.com.br – 208.67.220.220
;; connection timed out; no servers could be reached

Significa que o tráfego UDP/53 está sendo bloqueado e você deve tentar um dos próximos métodos.

Método 4: TCP Over DNS

Aqui a coisa começa a ficar interessante. Já imaginou a possibilidade de trafegar qualquer tipo de dados apenas usando o sistema de DNS? Isso me ocorreu justamente da última vez que conectei em um hotspot num aeroporto, e quando fui pesquisar sobre, descobri que o conceito era bem mais velho do que eu imaginava.

Existem diversas implementacoes de TCP over DNS, sendo as mais famosas: Ozymandns (com um fork aqui), NSTX, entre outras. Andei brincando um pouco com elas, e a que trouxe melhores resultados foi a da Analogbit, feita em Java.

A configuração e uso destes softwares não é exatamente trivial e eu não vou detalhar aqui instruções específicas, mas você já é um menino grandinho o suficiente para se virar

Não dá para esperar muito da performance, e bem, na prática voce só vai conseguir uma conexão extremamente lenta, ainda assim, e melhor que nada. Utilize apenas como último recurso!

De qualquer forma, dá pra chegar a conclusão de que é impossível existir um controle 100% efetivo de filtragem de internet

Método 5: TCP Over ICMP

(Esse artigo ainda não foi terminado Volte algum dia para ler o restante!)

Novo Equipamento
O meu já relativamente velho Linksys WRT54-GC, apesar de ser muito pequeno e simpático e nunca ter me dado problemas nos últimos anos, mesmo operando 24/7, não possui uma quantidade de memória que pudesse ser aproveitada para instalação de Linux (Apenas 1MB de memória Flash).
O novo modelo escolhido foi o Asus WL520-GU, basicamente por causa de 3 critérios:

• É um equipamento barato.
• É compatível com Linux (4MB de memória Flash, 16MB de Ram).
• Possui além das 5 portas Ethernet, uma porta USB.

Fiz a compra do mesmo no Ebay, por cerca de US$45 dolares (já inclusa a taxa de entrega) de um vendedor de Hong Kong. Infelizmente a entrega foi demorada, mais de 3 meses, contando com o desembaraço do produto na Receita Federal. Inicialmente quiseram me cobrar quase R$200 de impostos, mas após a reavaliação que solicitei, o valor baixou para R$65. O valor total do produto acabou me saindo cerca de R$170 reais, algo bem razoavel em comparação aos preços de dispositivos similares por aqui.

Firmware Livre versus Firmware Proprietário:
Enquanto o firmware proprietário traz as features padrão de todos os roteadores wireless (DHCP, Firewall, UPnP, Port Forwarding, etc e especificamente neste modelo, compartilhamento de impressora USB), o Firmware Livre conta com tudo isso e muitas outras features que geralmente são encontradas apenas em caríssimos network appliances, como:

• Múltiplos SSIDs;
• QoS / Limitação de banda;
• Hotspots;
• Servidor Web/FTP/SSH/Telnet;
• Múltiplas WANs com Balanceamento de Links;
• Cliente de VPN e Voip;
• Possibilidade de rodar aplicações customizadas, como servidor web, cliente torrent, etc.

Só para mencionar algumas.

Escolha da “distro”: OpenWRT vs DD-WRT.
Pesquisando um pouco sobre essas duas “Distros” de Linux para roteadores, dá pra resumir de forma bem grosseira, que:

• DD-WRT é a uma solução out-of-the box; a escolha para quem quer simplesmente “instalar e esquecer” – Traz tudo pré configurado, e praticamente todas as opções podem ser configuradas através da sua interface web, que é bastante completa.
• OpenWRT é a escolha para quem quer “sujar as mãos” e customizar seu sistema ao máximo. Traz por padrão uma interface básica, e não espere que esteja tudo funcionando após o flash do firmware. Contudo, trata-se se algo modular, que o usuário pode adequar perfeitamente a suas necessidades se quiser investir o tempo.

Existem alguns aspectos mais obscuros:
O Objetivo do OpenWRT é o de ser uma implementação realmente livre. Todos os componentes que a compoem são completamente open source.
Já o DD-WRT certamente não é algo que o Stallman recomendaria – Os desenvolvedores mantém uma versão paga com mais funcionalidades. Além disso, a interface Web utilizada foi criptografada de forma a não poder ser customizada – Os desenvolveres alegam que isso é para frear o comércio de customizações do DD-WRT, mas essa eu pessoalmente não engoli. Claras violações à GPL.

De qualquer forma, preferi a simplicidade do DD-WRT sobre o OpenWRT, ao menos por enquanto. Assim que conseguir um tempinho e um equipamento extra para brincar, irei dar mais atenção ao OpenWRT. Desta forma, todos os procedimentos aqui irão ser explicados com base no DD-WRT.

Instalação:

Antes de tudo, verifique se o seu roteador é suportado aqui. <http://www.dd-wrt.com/wiki/index.php/Supported_Devices>

Basicamente, os requisitos para isso é que ele possua um chipset compatível, com Atheros ou Broadcom e uma quantidade de memória flash mínima (2MB para Broadcom, 4MB para Atheros). Se estiver pensando em comprar um novo equipamento para este fim, preste bastante atenção nas quantidades de memória Flash e Ram disponíveis – Vale a regra do quanto mais, melhor. Na verdade a quantidade de memória Flash acaba sendo o fator crucial: 2MB é apenas o mínimo possível para instalar as capacidades básicas, com 4MB você pode instalar o sistema standard sem muita folga e com 8MB ou mais, você já pode instalar todas as features opcionais.

1) Escolha a versão do Firmware e faça o download:

Existem versões diferentes do DD-WRT destinadas a quantidade de memória flash disponível em seu roteador: Micro, Mini, Nokaid, Standard, VOIP, VPN e Mega. As funcionalidade de cada uma você pode consultar aqui.

Os build mais recentes geralmente são postados aqui.

A última versão disponível no momento em que escrevo isso é a v24sp2 build 1188

A versão “especial” do firmware, que possui capacidades de QoS extendidas (controle de banda por velocidade – na versão free isso só é possível com prioridade) e é vendida no site. Se alguém tiver interesse, posso disponibilizar aqui eventualmente.

Note que esta é a versão v24sp1, enquanto a última free já é a v24sp2.
Tendo a versão do firmware escolhida e baixada, vamos para o próximo passo:

2) Atualizando a memória flash com o novo firmware.

Esse processo pode variar de dispositivo para dispositivo – O ideal é que você siga as instruções contidas no Wiki específicas para o seu.
O primeiro flash, de transição do firmware do fabricante para o DD-WRT costuma ser o mais “chato”. Uma vez que você tiver qualquer versão do DD-WRT instalada, a atualização para outra versão ou pacote ou mesmo para outro firmware (como o OpenWRT) será bem mais simples, podendo ser realizada pela interface Web do roteador.

Neste link seguem as instruções que segui para a atualização do meu roteador, o Asus WL520-GU.

3) Resultados

Após a atualização, a mudança que se nota é como da água para o vinho. As funcionalidades extras valem pelo esforço da atualização (que nem é tanta coisa assim). Fica a dica e o relato de que vale (muito) a pena mudar o firmware de seu roteador para linux