[UPDATED]Conectando ao inconectavel usando ssh e tsocks

Nesse exato momento estou em Parkland, o local onde estudo em Champaign-Urbana, Illinois, tentando baixar os fontes do kernel do FreeBSD afim de poder conectar a wireless(sim estou usando cabo). Uma vez que o FreeBSD nao tem suporte a minha bela placa Broadcom 4311 vou fazer uso do NDIS e usar os drivers windows pra carregar a placa.

Bom.. o problema eh: na rede onde eu estou conectado agora existe um firewall que limita as portas que pode sair trafego, ao contrario de muita sysadmin qua apenas bloqueia a entrada, soh libera portas 80, 22 e etc, aqui eles resolveram limitar as portas que podem ser usadas para saida de trafego. Isso me impede de utilizar o csup para baixar os fontes do kernel.

Ok, o manual do csup dah uma dica de como utilizar o ssh para encaminhar as conexoes, caso voce nao consiga estabelecer um conexao direta com o servidor do csup.

retirado do man csup:

USING ssh PORT FORWARDING
As an alternative to SOCKS, a user behind a firewall can penetrate it
with the TCP port forwarding provided by the Secure Shell package ssh.
The user must have a login account on the CVSup server host in order to
do this. The procedure is as follows:

1. Establish a connection to the server host with ssh, like this:

ssh -f -x -L 5999:localhost:5999 serverhost sleep 60

Replace serverhost with the hostname of the CVSup server, but type
`localhost' literally. This sets up the required port forwarding.
You must start csup before the 60-second sleep finishes. Once the
update has begun, ssh will keep the forwarded channels open as long
as they are needed.

2. Run csup on the local host, including the arguments `-h localhost'
on the command line.

O que o comando acima faz eh criar um socket na sua maquina(localhost) ouvindo na porta 5999, estabelece uma conexao normal na porta 22 do server serverhost. E agora todo bit enviado para localhost:5999(por isso voce tem que rodar csup -h localhost) sera encaminhado, dentro do tunel ssh, ateh o serverhost para a porta 5999 tambem. Que felizmente o serverhost vai estar escutando nesta porta e tudo vai funcionar. Sendo assim, voce precisa apenas conseguir sair na porta 22(conectar a qualquer servidor ssh na internet), e o trafego de dados na porta 5999 vai ser enviado "por dentro" dessa conexao ssh.

Muito bem, muito bonito. O detalhe eh que eu nao tenho um usuario em nenhum servidor cvsup do freebsd. Alias alguem tem!?

Sendo assim a dica acima eh furada, ao menos para a maioria dos mortais como eu e voce que nao temos um usuario nos servidores cvsup freebsd.. Que pena naum?! Ninguem disse que a vida era facil.

Num post anterior falei de como encaminhar as conexoes da sua maquina para outra. Leia aqui eh importante. Isso praticamente resolve meu problema. MAS, pra fazer uso deste recurso do ssh(Dynamic Port Forwarding) a aplicacao deve encaminhar as conexoes para a porta local, para que as mesmas sejam encaminhadas adiante. Se voce estah usando um navegador de internet com suporte a proxy, eh facil configurar. Meu problema eh que preciso utilizar uma aplicacao sem suporte a proxy. Eh ai que entra o tsocks. Com ele voce pode utilizar aplicativos que nao tem suporte a proxy, mas agora eles vao usar proxy :)

bom instalei ele no FreeBSD estava sob: /usr/ports/net/tsocks/
mas na verdade eu baixei o pacote: pkg_add -r tsocks eh mais rapido :)

No tsocks.conf removi tudo e adicionei a linha abaixo:

server = localhost

Numa outra aba estabeleci a conexao com um servidor que pode sair trafego na porta 5999, onde neste sim eu tenho usuario e senha, usando o comando:

ssh -D 1080 serverssh.quepodesair.naporta5999 -f sleep 10

O que a linha acima faz eh transformar sua maquina numa especie de proxy server escutando na porta 1080(-D 1080). Coloca o ssh em background(-f), mas para colocar em background tem que rodar um comando, alias, depois que esse comando termina a conexao termina. Entao a jogada eh rodar algo como sleep 10, e dentro desses 10 segundos comecar a conexao com o server lah da internet, que voce nao TINHA acesso antes. Porque, uma vez que a conexao com o server lah da internet estah estabelecida a conexao ssh vai continuar, assim que acabar a conexao com o server lah de fora, a conexao ssh acaba.

Ou pra simplificar as coisas rode apenas:

ssh -D 1080 serverssh.quepodesair.naporta5999

vai ficar "pra sempre" conectado, se nao tiver um timeout no shell. Faz o que tiver que fazer com o server lah da internet e desconecta depois.

Depois do socks proxy criado(ssh -D ...) eh hora de colocar o tsocks pra funcionar:

tsocks csup supfile

Todo o software que nao tem suporte a proxy e voce quer fazer ele passar a ter, use o tsocks appname

Tem um outro modo que voce pode ativar o tsocks e todos os comandos que voce digitar apos vao utilizar ele. Entao ao inves de digitar: tsocks appname, voce apenas ativar ele(leia o link abaixo) e digita appname

Com licensa agora tenho que ir compilar o driver da wireless. O proximo post vai ser isso provalmente.

[UPDATE]
Encontrei uma implementação de socks para windows e funciona no win 7 32 bits normalmente. É chamado SocksCap. Funciona que é um luxo!

http://www.linux.com/feature/54894

Redirecionamento X11 via SSH

Aproveitando que essa memória aqui tem bastante espaço colocar mais uma dicazinha:

Requerimentos para redirecionar as aplicações do X via SSH.

No servidor SSH:

arquivo /etc/ssh/sshd_config:

X11Forwarding yes

---

No cliente SSH:

arquivo /etc/ssh/ssh_config:

ForwardX11 yes

Log into the remote system and type xclock &. This starts a X clock program that can be used for testing the forwarding connection. If the X clock window is displayed properly, you have X11 forwarding working.

Retirado daqui.

Túnel via SSH

A idéia é bastante simples. Pode-se chamar de uma "VPN simples". Esse recurso pode ser usado quando se está em uma rede não segura e precisa criptografar o tráfego. Por exemplo, você está numa lan house, onde pode ter alguém "esnifando" (de sniffing) a rede , e precisa acessar um serviço que não possui criptografia.

Isso é chamado de Dynamic Port Forwarding e é um recurso que o SSH possui. Tudo o que você precisa é de um usuário em algum servidor rodando SSHD e que esse servidor tenha acesso liberado a internet. Para ficar mais fácil a compreensão de como o túnel é feito vamos supor um exemplo:

Você está em uma estação qualquer, chamaremos de Host1. Você tem uma conta em um servidor, com acesso a internet, chamado Server1 e deseja se conectar ao site www.terra.com.br

Alguns pontos a considerar:

• Server1 pode estar dentro de uma rede privada ou mesmo na internet em qualquer lugar do planeta;
• Host1 pode estar em qualquer lugar do planeta onde consiga se conectar à Server1;
  
• E o site do Terra está há duas quadras de onde eu estou escrevendo esse artigo. Mas isso não vem ao caso.

Para configurar Host1 precisamos apenas ter um cliente ssh. Pode ser no UNIX ou mesmo Windows. Depois do procedimento descrito a seguir, Host1 vai se tornar um servidor. O qual vai receber conexões e encaminhar para Server1 que vai fazer o papel de um proxy que suporta socks.

Configurar Host1 no Unix:

ssh -D 1080 joao@server1

Depois de estabelecida a conexão com server1 é só manter essa conexão ativa. E, teoricamente está pronto. Assim.. simples ou como diria os gringos out of the blue...

Nesse momento Host1 tornou-se um servidor que encaminha todas as conexões que chegam até ele com destino a porta 1080 para Server1.

Para fazer uso disso vá até seu navegador, por exemplo, e configure-o para usar proxy socks. No endereço do socks proxy vai localhost e a porta é a 1080. Pronto! Funcionando!


Configurar Host1 no Windows:

Como dito anteriormente, é necessário apenas um cliente SSH. Que no windows vai ser o Putty.
Aqui tem um vídeo de todo o processo incluindo a configuração do Putty.

Pra ser mais prático pode ser feito via linha de comando no windows também.

putty -ssh -D 1080 joao@server1

Estamos prontos para fazer a configuração do navegador, cliente MSN, seja lá o que for.
É a mesma coisa que fizemos antes. Configurar o software para utilizar proxy socks.


Só para deixar claro: A conexão é criptografada de Host1 até Server1. Do Server1 até o site do terra que é o nosso exemplo a conexão não é segura.

Links sobre o assunto:

http://www.debian-administration.org/articles/449
http://www.panix.com/~ruari/censorship.html
http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/portfwd-dynamic.html
http://www.ssh.com/support/documentation/online/ssh/adminguide/32/Dynamic_Port_Forwarding.html
http://www.irongeek.com/i.php?page=videos/sshdynamicportforwarding

Conexões SSH sem senha[atualizado]

É possível fazer logon no serviço SSH de um servidor remoto atráves de chaves(keys).


Nesse post, para melhor entendimento, vou tratar o esquema de autenticação como sendo cliente/servidor. Teremos o seguinte:

• Um servidor onde está rodando o daemon do SSH, esperando por conexões.
• Um cliente, uma estação qualquer, apartir da qual faremos a conexão ao servidor.

Vamos iniciar a configuração na máquina servidora:


Edite o arquivo de configuração do sshd, normalmente em: /etc/ssh/sshd_config

Confirme se a opção PubkeyAuthentication está setada como yes. Senão faça isso.

PubkeyAuthentication yes

Pronto!! No servidor é só isso.

Agora devemos criar uma chave pública, vá até o micro com o qual você costuma efetuar a conexão remota e execute como usuário:


A configuração na máquina cliente:


Gerando a chave localmente:

$ ssh-keygen -t dsa -b 1024

A opção -t especifica o tipo da chave a ser criada. Use rsa caso esteja usando o protocolo de versão 1 no servidor ou use dsa caso use o protocolo versão 2 no servidor. rsa é a padrão caso não especificado.

A opção -b especifica o número de bits da chave a ser criada. Para chaves RSA o tamanho mínimo é de 768 bits and o padrão é 2048. Geralmente, 2048 bits é considerado o suficiente. As chaves DSA precisam ser exatamente 1024 bits.

Vão ser feitas algumas perguntas durante a criação da chave pode ir confirmando com enter. Não vamos alterar nada.

Agora você tem sua chave de acesso e você deve enviá-la para o servidor com o qual você se conecta, para isto usaremos o ssh-copy-id.

$ ssh-copy-id -i ~/.ssh/id_dsa.pub usuario@IPdoServidor

Nas últimas versões me parece que não existe mais o comando ssh-copy-id. Portanto pode ser usado o comando genérico:

$ scp ~/.ssh/id_dsa.pub usuario@IPdoServidor:~/.ssh/authorized_keys

Substitua usuario pelo usuário usado na conexão com a outra máquina e IPdoServidor pelo IP da máquina remota.

Pronto, agora basta testar e conectar ao servidor.

$ ssh usuario@maquinaIP

Você deverá conectar-se sem precisar digitar a senha.

* Para garantir a segurança você deverá tomar cuidado com a chave gerada no seu diretório HOME na pasta .ssh, pois se um mal intencionado copia-la poderá logar-se na máquina remota sem utilizar a senha.



Encontrei esse tutorial aqui. Tomei a liberdade de modificar e deixá-lo mais mastigado.
Outra fonte:
http://www.debian-administration.org/articles/530


Feitoooo!!!!