Trabalho de Redes: SSH Aluno: Rogrio Magno da Silva Rodrigues Sistemas de Informao 7 B Faculdade Fortium

Protocolo SSH

Protocolo SSH

O protocolo de rede SSH foi criado para permitir conexes seguras entre mquinas e permitir a execuo de comandos remotos de shell. Alis, da que deriva o nome deste protocolo. SSH vem de Secure SHell. Antes deste protocolo usava-se o Telnet e o RLogin, que tambm permitem fazer login num computador multi-usurio atravs de uma mquina remota que esteja na mesma rede. Acontece que o trfego IP normal possui as seguintes fraquezas que podem ser exploradas para comprometer a segurana:

Autenticao deficiente baseada em endereos IP que podem ser falsificados (spoofing) ou em senhas que podem ser farejadas (sniffing). Falta de privacidade porque os pacotes podem ser farejados (sniffing). Falta de proteo de integridade porque as conexes podem ser sequestradas (hijacked}.

O SSH foi projetado para eliminar estes problemas oferecendo um mecanismo de autenticao mais robusto para identificar tanto as mquinas quanto os usurios e para assegurar conexes seguras. Este protocolo pode substituir as funes do RSH, do RCP e do RLogin e, em muitos casos, tambm pode substituir o Telnet e o FTP, alm de expandir outras conexes (por exemplo, entre clientes e servidores X, POP ou NNTP). O SSH foi criado em 1995 por Tatu Ylonen, um pesquisador da Universidade de Tecnologia de Helsinki, Finlndia. Aps um incidente de segurana na universidade, Ylonen criou a tecnologia da Secure Shell para criptografar os dados transmitidos em redes TCP/IP. A primeira verso recebeu o nome de SSH1. Em 2006, a stima verso do SSH foi aceita como padro pela IETF, adquirindo o status de tecnologia padro junto com o HTTP, TCP e IP. Sistemas operacionais multi-usurio, como UNIX, Linux e VMS, geralmente oferecem uma interface de comando de linha que permite digitar os comandos desejados, inclusive os do SSH (se estiver disponvel). Mas nem tudo precisa ser feito "na unha". Existem interfaces grficas excelentes para fazer este tipo de conexo segura. Dois exemplos so o PuTTY e o WinSCP (costumo usar os dois) que voc encontra na seo de downloads da Aldeia. Procure em Informtica/Shell. O SSH foi projetado para fornecer autenticao e comunicao seguras atravs de canais inseguros. Permite logins, execuo de comandos e cpias remotas substituindo o RLogin, RSH, RCP e RDist. Possui as seguintes caractersticas: Agentes de autenticao podem guardar as chaves RSA de autenticao de usurio. Estes agentes rodam no laptop ou mquina local do usurio e no h necessidade de guardar as chaves de autenticao RSA em outro local. O SSH transfere automaticamente a conexo para o agente de autenticao, nunca revelando as chaves. Os protocolos so usados apenas para verificar se o agente possui a chave do usurio. O cliente possui arquivos de configurao customizveis, tanto para o sistema quanto por usurio. Opes diferentes podem ser especificadas para hosts diferentes. Se a mquina servidora no estiver rodando sshd, um aviso de alerta mostrado e o ssh automaticamente retrocede para usar o rsh convencional. A compresso gzip de todos os dados, incluindo X11 redespachado e dados de portas TCP/IP, opcional.

Administrao Segura de Sistemas

O Secure Shell foi originalmente criado para propiciar acessos seguros a terminais (shell) de servidores Unix em redes TCP/IP. Hoje em dia, um dos usos mais frequentes do SSH o de substituir conexes de terminais baseadas em Telnet entre estaes de trabalho Windows e servidores Unix/Linux/Windows. O principal grupo de usurios de acessos seguros de terminais so administradores de sistema, que adotaram o Secure Shell como padro de-facto na administrao remota de servidores Unix e outros dispositivos de rede.

Conectividade Segura de Aplicaes

O Secure Shell disponibiliza dois modos diferentes de proteger conexes de aplicaes entre estaes de trabalho de usurios finais e servidores de aplicao. Em aplicaes de linha de comando, ele pode ser usado como um terminal seguro que substitui acessos ao host baseados em Telnet. Por outro lado, a funcionalidade de redespacho (forward) de portas pode ser usada para "tunnelar" conexes TCP de aplicaes sem a necessidade de substituir o programa e a interface do usurio. A capacidade de redirecionamento de portas faz do Secure Shell uma soluo genrica para proteger do comeo ao fim conexes de protocolos de aplicaes.

Entendendo SSH
O SSH permite administrar mquinas remotamente (executando tanto comandos em modo texto quanto aplicativos grficos), permite transferir arquivos de vrias formas diferentes e, como se no bastasse, permite tambm encapsular outros protocolos, permitindo, por exemplo, acessar uma sesso do VNC atravs de um tnel seguro. A grande vantagem do SSH sobre outras ferramentas de acesso remoto a grande nfase na segurana. Um servidor SSH bem configurado virtualmente impenetrvel e voc pode acess-lo de forma segura, mesmo que a sua rede local esteja comprometida. Ele utiliza um conjunto de tcnicas de criptografia para assegurar que apenas as pessoas autorizadas tenham acesso ao servidor, que todos os dados transmitidos sejam impossveis de decifrar e que a integridade da conexo seja mantida. So previstas respostas para diversos tipos de ataques conhecidos. O SSH detecta casos em que o servidor tenha sido substitudo por outra mquina, situaes nas quais se tenta injetar dados na conexo (ou seja, tirar proveito de uma conexo aberta para incluir pacotes com comandos adicionais) e inclui at mesmo tcnicas de "despiste", que tornam muito mais complicado descobrir em qual pacote encriptado foi transmitida a senha de acesso, por exemplo, dificultando a vida de quem pretende descobrir a senha usando um ataque de fora bruta. A idia central que, mesmo em situaes onde seja fcil interceptar a transmisso (como no caso de uma rede wireless pblica), seja impossvel descobrir o contedo dos pacotes, devido encriptao. possvel ainda, utilizar um par de chaves em vez de uma senha como forma de autenticao. Nesse caso, alm de possuir a chave privada (um arquivo que pode ser salvo no HD, em um pendrive ou mesmo em um smartcard), preciso saber a passphrase, que pode ser uma senha especialmente longa e difcil de adivinhar. Voc poderia argumentar que qualquer algoritmo de encriptao pode ser quebrado via fora bruta (onde simplesmente so testadas todas as possibilidades possveis, at

encontrar a combinao correta), de forma que nenhum sistema de encriptao inteiramente seguro. Entretanto, ataques de fora bruta s so realmente viveis contra chaves de 40 ou 64 bits; acima disso invivel, pois a cada bit adicionado, o processo torna-se exponencialmente mais demorado. Um exemplo de protocolo pouco seguro o WEP de 64 bits (que na verdade utiliza uma chave de 40 bits), usado em redes wireless pouco protegidas. Ele pode ser quebrado em pouco tempo, caso voc consiga capturar um volume considervel de transmisses usando um sniffer (um programa que captura a transmisso da rede, como o Kismet). O DES, um dos algoritmos mais tradicionais, que usa chaves de 64 bits (reais), pode ser quebrado em menos de um dia, caso voc tenha acesso a um cluster de 100 mquinas com processadores Xeon ou Opteron quad-core. Uma chave de 64 bits cerca de 16 milhes de vezes mais difcil de quebrar via fora bruta do que uma de 40 bits, como as que eram utilizadas no SSL dos navegadores a at poucos anos. Uma chave de 128 bits por sua vez, (arredondando) 18.447.000.000.000.000.000 vezes mais demorada de quebrar que uma de 64 bits, de forma que, uma chave de 64 bits pode ser quebrada caso voc tenha o tempo e os recursos necessrios disposio, mas uma de 128 (sem brechas conhecidas) impossvel de quebrar com tecnologia atual. O perigo no caso dos algoritmos de encriptao no so propriamente os ataques de fora bruta (que exigem muito tempo e recursos), mas sim falhas que permitam descobrir a chave usada em menos tempo. As verses originais do WEP (o sistema de encriptao para redes wireless anterior ao WPA), por exemplo, podiam ser quebradas rapidamente devido a um conjunto de falhas no algoritmo usado, o que levou os fabricantes a atualizarem rapidamente todos os seus produtos. Outro exemplo o sistema usado na encriptao dos DVDs, que quebrado em poucos segundos por uma mquina atual, utilizando um algoritmo de poucas linhas. Felizmente, este no o caso dos algoritmos usados no SSH. Por serem abertos, qualquer falha similar que pudesse eventualmente existir j teria sido descoberta e corrigida. O SSH usado em tantos servidores importantes que uma brecha grave poderia (literalmente) parar o mundo. Por isso, todo o cdigo exaustivamente auditado por uma variedade de empresas e rgos governamentais. O SSH utiliza chaves assimtricas para fazer a autenticao. As chaves assimtricas so um sistema muito interessante, onde temos um par de chaves em vez de uma nica chave simtrica. Uma (a chave pblica), permite apenas encriptar dados, enquanto a segunda (a chave privada) permite desencriptar as informaes embaralhadas pela primeira. O grande segredo que qualquer informao embaralhada usando a chave pblica pode ser recuperada apenas usando a chave privada correspondente. Como o nome sugere, a chave pblica pode ser distribuda livremente, pois serve apenas para gerar as mensagens encriptadas, sem permitir l-las posteriormente. Quando voc se conecta a um servidor SSH, seu micro e o servidor trocam suas respectivas chaves pblicas, permitindo que um envie informaes para o outro de forma segura. Atravs deste canal inicial feita a autenticao, seja utilizando login e senha, seja utilizando chave e passphrase (como veremos a seguir). At aqui, tudo feito utilizando chaves de 512 bits ou mais (de acordo com a configurao). O problema que, embora virtualmente impossvel de quebrar, este nvel de encriptao demanda um volume muito grande de processamento. Se todas as informaes fossem transmitidas desta forma, o SSH seria muito lento. Para solucionar este problema, depois de fazer a autenticao, o SSH passa a utilizar um algoritmo mais simples (que demanda muito menos processamento) para transmitir os

dados. Por padro utilizado o 3DES (triple-DES), que utiliza uma combinao de trs chaves DES, de 64 bits cada. As chaves so trocadas periodicamente durante a conexo, o que torna o sistema quase impossvel de quebrar. Na configurao do servidor e/ou cliente, possvel especificar outro algoritmo, como o Blowfish. Isso garante uma boa relao entre segurana e desempenho. O SSH dividido em dois mdulos. O sshd o mdulo servidor, um servio que fica residente na mquina que ser acessada, enquanto ossh o mdulo cliente, um utilitrio que voc utiliza para acess-lo. Para instalar o SSH no servidor, basta instalar o pacote "openssh-server" usando o gerenciador de pacotes, como em: # apt-get install openssh-server ou: # yum install openssh-server Na maioria dos casos, ao fazer uma instalao em modo servidor do sistema o SSH ser instalado e configurado para subir no boot automaticamente, mas, de qualquer forma, no custa verificar. Nas distribuies derivadas do Debian, ele ativado usando o servio "ssh", como em: # /etc/init.d/ssh start Nas derivadas do Red Hat, incluindo o Mandriva e o CentOS o servio se chama sshd: # service sshd start No caso do CentOS, voc precisa usar o comando "chkconfig sshd on" para ativar a inicializao automtica do servio caso o pacote seja instalado depois da instalao do sistema: # chkconfig sshd on Como de praxe, necessrio manter a porta 22 usada pelo SSH aberta no firewall do servidor. O SSH permite fazer quase tudo atravs dessa nica porta, atendendo a diversos clientes simultneos. Concluindo, para usar o SSH no seu micro de trabalho necessrio ter instalado apenas o pacote "openssh-client". Veja que o cliente e o servidor so intencionalmente mantidos em pacotes separados justamente para permitir que voc instale apenas um ou outro conforme necessrio. A configurao do servidor, independentemente da distribuio usada, vai no arquivo "/etc/ssh/sshd_config", enquanto a configurao do cliente vai no "/etc/ssh/ssh_config". Note que muda apenas um "d" entre os dois; cuidado para no confundir car com batata doce. ;) Outra observao que alm do OpenSSH, que abordo aqui, existem outras verses do SSH, como o Tectia (uma verso comercial, disponvel no http://ssh.com) e o SunSSH que, embora conservem diferenas no funcionamento e na configurao, so compatveis entre si. O SSH , na verdade, um protocolo aberto e no o nome de uma soluo especfica.

O uso bsico do SSH bastante simples, j que basta usar o comando "ssh login@servidor" para acessar o servidor remoto e, a partir da, rodar os comandos desejados. Entretanto, essa apenas a ponta do iceberg. O SSH to rico em funes que at mesmo os administradores mais experientes raramente usam mais do que um punhado das funes disponveis. Vamos ento a uma viso mais aprofundada do SSH, comeando com dicas de configurao:

Configurao do Cliente SSH

Ao ser ativado, o padro do servidor SSH permitir acesso usando qualquer uma das contas de usurio cadastradas no sistema, pedindo apenas a senha de acesso. Para acessar o servidor "192.168.0.2", usando o login "morimoto", por exemplo, o comando seria: $ ssh morimoto@192.168.0.2 Em vez de usar a arroba, voc pode tambm especificar o login usando o parmetro "-l" (de login), como em: $ ssh -l morimoto 192.168.0.2 Voc pode tambm acessar o servidor usando o domnio, como em: $ ssh morimoto@gdhpress.com.br Caso voc omita o nome do usurio, o SSH presume que voc quer acessar usando o mesmo login que est utilizando na mquina local. Se voc est logado como "tux", ele tentar fazer login usando uma conta "tux" no servidor remoto. Naturalmente, s funciona caso voc use o mesmo login em ambas as mquinas. Ao acessar micros dentro da rede local, voc pode tambm cham-los pelo nome, como em "ssh morimoto@servidor". Neste caso, voc precisar primeiro editar o arquivo "/etc/hosts" (no cliente), incluindo os nmeros de IP das mquinas e os nomes correspondentes. O formato deste arquivo bem simples, basta fornecer o IP e o nome da mquina correspondente, um por linha, como em: 127.0.0.1 localhost 192.168.0.2 servidor 192.168.0.6 athenas A configurao do arquivo "/etc/hosts" vale apenas para a sua prpria mquina, ele nada mais do que um arquivo com aliases. Se voc quiser que os apelidos sejam vlidos tambm para as demais mquinas da rede, a melhor opo configurar um servidor DNS de rede local. Voltando configurao do SSH, vamos a algumas opes importantes dentro da configurao do cliente SSH, que vo no arquivo "/etc/ssh/ssh_config":

Aplicativos grficos: Alm de oferecer acesso via linha de comando, o SSH permite rodar aplicativos grficos remotamente (X11 forwarding). Muitas distribuies trazem o recurso desabilitado por padro. Nestes casos, edite o arquivo "/etc/ssh/ssh_config" (no cliente) e substitua a linha "ForwardX11 no" por: ForwardX11 yes Outra opo adicionar o parmetro "-X" ao se conectar, como em "ssh -X tux@192.168.0.1". A partir da, voc pode chamar os aplicativos grficos normalmente, como se estivesse usando um terminal local. O maior problema com o uso de aplicativos grficos via SSH que ele s funciona satisfatoriamente dentro da rede local. Via Internet os aplicativos grficos ficam realmente muito lentos (mesmo em uma conexo de 4 ou 8 megabits), pois o protocolo do X otimizado para uso local, com uso intensivo de pacotes de retorno e sem nenhum tipo de cache. Isso faz com que muitos administradores desabilitem o X11 forwarding no prprio servidor. Para rodar aplicativos grficos de forma segura via Internet, a melhor soluo usar o NX Server (que veremos em detalhes mais adiante). Ele um sistema de acesso remoto baseado no SSH, que utiliza um protocolo bastante otimizado. Nele voc tem um desktop completo (similar ao VNC), mas com um desempenho muito superior, mesmo em conexes via modem. Compresso: No caso de servidores acessveis via Internet, voc pode reduzir um pouco o consumo de banda ativando a compresso de dados via gzip, o que feito adicionado a linha: Compression = yes Voc pode tambm ativar a compresso adicionando a opo "-C" na hora de se conectar. Quase todas as opes do cliente SSH podem ser especificadas tanto no arquivo, quanto via linha de comando. Keep Alive: Outro problema comum relacionado ao SSH a conexo ser fechada pelo servidor depois de alguns minutos de inatividade. Em muitas situaes voc quer manter a conexo aberta por longos perodos, sem precisar ficar dando um "ls" ou um "pwd" a cada dois minutos para manter a conexo aberta. Voc pode evitar o problema fazendo com que o prprio cliente mande pacotes periodicamente a fim de manter a conexo aberta. Para ativar o recurso, adicione a opo "ServerAliveInterval" no arquivo, especificando o intervalo entre o envio dos pacotes (em segundos): ServerAliveInterval 120 Este um exemplo de arquivo "/etc/ssh/ssh_config", configurado com as opes que vimos at aqui (excluindo os comentrios): ForwardX11 yes Compression = yes Port 22 ServerAliveInterval 120 Como em outros arquivos de configurao, voc no precisa se preocupar em incluir cada uma das opes disponveis, pois o SSH simplesmente usa os valores default para

as opes no includas no arquivo. Com isso, voc precisa se preocupar apenas com as opes que conhece, omitindo as demais. Verificao do servidor: Como parte das verificaes de segurana, o SSH utiliza tambm um sistema baseado em chaves assimtricas para verificar a identidade do servidor. O servidor possui uma chave pblica, que enviada ao cliente na primeira conexo. As identificaes de todos os servidores conhecidos ficam armazenadas no arquivo ".ssh/known_hosts", dentro do seu diretrio home. Sempre que voc se conecta da em diante, o cliente SSH envia um "desafio" ao servidor, uma frase encriptada usando a chave pblica (do servidor), que s pode ser descoberta usando a chave privada. Isso previne um tipo de ataque muito comum chamado "man in the middle" (que poderia ser traduzido para "intermedirio", ou "impostor"), em que algum simplesmente substitui o servidor por outra mquina, usando o mesmo IP, ou sabota o servidor DNS da rede (ou do provedor de acesso) de forma que ele entregue um IP forjado quando voc tenta acessar seu servidor baseado no domnio. O servidor falso pode ser configurado para gravar sua senha e responder com uma mensagem do tipo "O servidor est em manuteno, tente novamente daqui a algumas horas". Dessa forma, ele vai ter no apenas acesso sua senha, mas tempo de us-la para acessar o servidor verdadeiro sem que voc desconfie. Entretanto, isso previsto dentro do design do SSH; ele percebe que a identificao do servidor mudou e lhe avisa do problema:

Para continuar preciso que voc remova a linha com a identificao do servidor salva no arquivo .ssh/know_hosts, dentro do diretrio home do usurio que est utilizando. Isso pode ser feito de duas formas. A primeira remover a chave usando o comando "ssh-keygen -R", seguido pelo endereo IP ou o domnio do servidor (o mesmo que voc especifica ao se conectar a ele), como em: # ssh-keygen -R 192.168.1.200 /home/gdhn/.ssh/known_hosts updated. Original contents retained as /home/gdhn/.ssh/known_hosts.old

Como pode ver, o comando substituiu a edio manual do arquivo, removendo a linha correspondente ao servidor e salvando um backup do arquivo original por precauo. A segunda opo editar diretamente o arquivo ".ssh/known_hosts", comentando ou removendo a linha referente ao servidor (deixando as demais). Dentro do arquivo, voc ver uma longa linha para cada servidor acessado, comeando com o endereo IP ou o nome de domnio usado no acesso. Em qualquer um dos dois casos, da prxima vez que tentar se conectar, o SSH exibe uma mensagem mais simptica, perguntando se voc quer adicionar a nova chave: The authenticity of host '192.168.1.200 (192.168.1.200)' can't be established. RSA key fingerprint is f1:0f:ae:c6:01:d3:23:37:34:e9:29:20:f2:74:a4:2a. Are you sure you want to continue connecting (yes/no)? No existe forma de fazer com que o cliente SSH adicione as novas chaves automaticamente, isso seria uma brecha de segurana. sempre preciso primeiro remover a chave antiga manualmente. As chaves de identificao so geradas durante a instalao do SSH e salvas nos arquivos "/etc/ssh/ssh_host_rsa_key" e "/etc/ssh/ssh_host_dsa_key" (no servidor). Para no disparar o alarme nos clientes quando precisar reinstalar o sistema no servidor, ou quando substitu-lo por outra mquina, salve os dois arquivos em um pendrive e restaure-os depois da instalao. Voc pode fazer isso mesmo ao migrar para outra distribuio, pois as localizaes dos dois arquivos no mudam. Uma ltima opo seria desabilitar a checagem das chaves, adicionando a opo "StrictHostKeyChecking no" na configurao dos clientes. Contudo, isso no recomendvel, pois desabilita completamente a checagem, abrindo brechas para ataques.

Configurao do Servidor SSH

Voc pode configurar vrias opes relacionadas ao servidor SSH, incluindo a porta TCP a ser usada editando o arquivo "/etc/ssh/sshd_config". Assim como no caso da configurao do cliente, a maior parte das opes dentro do arquivo podem ser omitidas (pois o servidor simplesmente utiliza valores default para as opes que no constarem no arquivo), mas, de qualquer forma, saudvel especificar todas as opes que conhece: alm de evitar enganos, uma forma de praticar e memorizar as opes. Porta: Uma das primeiras linhas a: Port 22 Esta a porta que ser usada pelo servidor SSH. O padro usar a porta 22. Ao mudar a porta do servidor aqui, voc dever usar a opo "-p" ao conectar a partir dos clientes para indicar a porta usada, como em: # ssh -p 2222 morimoto@gdhn.com.br

Outra opo editar o arquivo "/etc/ssh/ssh_config" (nos clientes) e alterar a porta padro usada por eles. Mudar a porta padro do SSH uma boa idia se voc est preocupado com a segurana. Muitos dos ataques "casuais" (quando o atacante simplesmente varre faixas inteiras de endereos, sem um alvo definido), comeam com um portscan genrico, onde feita uma varredura em faixas inteiras de endereos IP, procurando por servidores com portas conhecidas abertas, como a 21, a 22 e a 80. Isso torna o teste mais rpido, permitindo localizar rapidamente um grande volume de hosts com portas abertas. A partir da, os ataques vo sendo refinados e direcionados apenas para os servidores vulnerveis encontrados na primeira varredura. Colocar seu servidor para escutar uma porta mais escondida, algo improvvel como a porta 32456 ou a 54232 reduz sua exposio. Controle de acesso: Logo abaixo vem a opo "ListenAddress", que permite limitar o SSH a uma nica interface de rede (mesmo sem usar firewall), til em casos de micros com duas ou mais placas; o tpico caso em que voc quer que o SSH fique acessvel apenas na rede local, mas no na Internet, por exemplo. Digamos que o servidor use o endereo "192.168.0.1" na rede local e voc queira que o servidor SSH no fique disponvel na Internet. Voc adicionaria a linha: ListenAddress 192.168.0.1 Note que especificamos nesta opo o prprio IP do servidor na interface escolhida, no a faixa de IP's da rede local ou os endereos que tero acesso a ele. Protocolo: Atualmente utilizamos o SSH 2, mas ainda existem alguns poucos clientes que utilizam a primeira verso do protocolo. Por padro, o servidor SSH aceita conexes de clientes que utilizam qualquer um dos dois protocolos, o que indicado na linha: Protocol 2,1 O protocolo SSH 1 tem alguns problemas fundamentais de segurana, por isso recomendvel desativar a compatibilidade com ele, aceitando apenas clientes que usam o SSH 2. Neste caso, a linha fica apenas: Protocol 2 Restringir a verso do protocolo ajuda a melhorar a segurana, pois evita que usurios utilizando clientes SSH antigos abram brechas para ataques. Existem, por exemplo, muitos clientes SSH para uso em celulares que suportam apenas o SSH 1 e utilizam algoritmos fracos de encriptao. Desativando a compatibilidade com o SSH 1 voc corta o mal pela raiz. Usurios e senhas: Outra opo interessante, geralmente colocada logo abaixo, a: PermitRootLogin yes Esta opo determina se o servidor aceitar que usurios se loguem como root. Do ponto de vista da segurana, melhor deixar esta opo como "no", pois assim o usurio precisar primeiro se logar usando um login normal e rodar comandos como root usando o "sudo" ou "su -": PermitRootLogin no

Dessa forma, preciso saber duas senhas, ao invs de saber apenas a senha do root, eliminando a possibilidade de algum atacante obstinado conseguir adivinhar a senha de root e, assim, obter acesso ao servidor. Por padro, o SSH permite que qualquer usurio cadastrado no sistema se logue remotamente, mas voc pode refinar isso atravs da opo "AllowUsers", que especifica uma lista de usurios que podem usar o SSH. Quem no estiver na lista, continua usando o sistema localmente, mas no consegue se logar via SSH. Isso evita que contas com senhas fracas, usadas por usurios que no tm necessidade de acessar o servidor remotamente coloquem a segurana do sistema em risco. Para permitir que apenas os usurios "joao" e "maria" possam usar o SSH, por exemplo, adicione a linha: AllowUsers joao maria Voc pode ainda inverter a lgica, usando a opo "DenyUsers". Neste caso, todos os usurios cadastrados no sistema podem fazer login, com exceo dos especificados na linha, como em: DenyUsers ricardo manuel Outra opo relacionada segurana a: PermitEmptyPasswords no Esta opo faz com que qualquer conta sem senha fique automaticamente desativada no SSH, evitando que algum consiga se conectar ao servidor "por acaso" ao descobrir a conta desprotegida. Lembre-se de que a senha justamente o ponto fraco do SSH. De nada adianta usar 2048 bits de encriptao se o usurio escreve a senha em um post-it colado no monitor, ou deixa a senha em branco. Banner: Alguns servidores exibem mensagens de advertncia antes do prompt de login, avisando que todas as tentativas de acesso esto sendo monitoradas ou coisas do gnero. A mensagem especificada atravs da opo "Banner", onde voc indica um arquivo de texto com o contedo a ser mostrado, como em: Banner = /etc/ssh/banner.txt X11 Forwarding: Alm de ser usada na configurao dos clientes, a opo "X11Forwarding" pode ser tambm includa na configurao do servidor: X11Forwarding yes Ela determina se o servidor permitir que os clientes executem aplicativos grficos remotamente. Se o servidor for acessado via Internet ou se possui um link lento, voc pode deixar esta opo como "no" para economizar banda. Desta forma, os clientes podero executar apenas comandos e aplicativos de modo texto. Note que ao usar "X11Forwarding no" o encaminhamento recusado pelo prprio servidor, de forma que o usurio no consegue rodar aplicativos grficos mesmo que a opo esteja ativa na configurao do cliente. - SFTP: O SSH inclui um mdulo de transferncia de arquivos (o SFTP), que veremos em detalhes a seguir. Ele ativado atravs da linha: Subsystem sftp /usr/lib/sftp-server

 realmente necessrio que esta linha esteja presente para que o SFTP funcione. Comente esta linha apenas se voc realmente deseja desativ-lo.

Atualizao
Por mais seguras que sejam suas senhas, sempre existe uma pequena possibilidade de que um atacante descubra alguma delas, observando enquanto voc digita no teclado, ou que simplesmente consiga adivinh-la a partir de informaes pessoais ou de senhas antigas. Se voc tem o hbito de usar as mesmas senhas em vrios locais, a possibilidade cresce, pois muitos servios armazenam ou transmitem senhas de formas no seguras. Com isso, as senhas acabam sendo o ponto fraco da segurana. Como de praxe, o SSH oferece uma resposta para o problema. Em vez de depender unicamente da senha como forma de autenticao, voc pode utilizar um par de chaves de autenticao, onde a chave pblica instalada nos servidores que sero acessados e a chave privada (que nunca sai da sua mquina) protegida por uma passphrase, sem a qual a chave se torna intil. Nesse caso, temos uma segurana de dois nveis, em que preciso saber a passphrase e, alm dela, ter a chave privada, um arquivo salvo no HD ou em um pendrive, algo similar ao sistema bancrio, onde voc precisa ter o carto e saber a senha. Para gerar o par de chaves, use (no cliente) o comando: $ ssh-keygen -t rsa Ele deve ser executado usando seu login de usurio (o mesmo que voc usa para acessar os servidores remotos), no como root: Generating public/private rsa key pair. Enter file in which to save the key (/home/morimoto/.ssh/id_rsa): Created directory '/home/morimoto/.ssh'. Enter passphrase (empty for no passphrase): ******** Enter same passphrase again: ******** Your identification has been saved in /home/morimoto/.ssh/id_rsa. Your public key has been saved in /home/morimoto/.ssh/id_rsa.pub. The key fingerprint is: ff:28:26:f6:87:67:9f:4c:9a:c8:0a:3b:21:81:88:b4 morimoto@athenas A passphrase pode ser desde uma senha "normal", com 8 ou 12 caracteres, at uma frase complexa, sem limite de tamanho; o importante que no seja algo fcil de adivinhar. A passphrase , na verdade, um componente da chave de encriptao; sem ela impossvel usar a chave. O comando gerar os arquivos ".ssh/id_rsa" e ".ssh/id_rsa.pub" dentro do seu diretrio home, que so, respectivamente, sua chave privada e sua chave pblica. O ".ssh/id_rsa" um arquivo secreto, que deve usar obrigatoriamente o modo de acesso "600" (que voc define usando o chmod), para evitar que outros usurios da mquina possam l-lo. Muitos servidores recusam a conexo caso os arquivos estejam com as permisses abertas. Depois de gerar seu par de chaves, falta o comando final, que instala a chave pblica no servidor, permitindo que ela seja usada para autenticao:

$ ssh-copy-id -i ~/.ssh/id_rsa.pub login@servidor Como o nome sugere, o comando "ssh-copy-id" copia sua chave pblica, instalando-a no servidor. Ao us-lo, substitua o "login" pelo seu login de usurio e o "servidor" pelo endereo IP ou o domnio do servidor. Ao ser executado, ele abrir uma conexo via SFTP (ainda utilizando seu login e senha de acesso), que usada para instalar a chave pblica (o arquivo ".ssh/id_rsa.pub", dentro do seu home) no diretrio correspondente do servidor. Naturalmente, para que a transferncia funcione, necessrio que o SFTP esteja ativo na configurao do servidor. Caso voc utilize o mesmo login de usurio nas duas mquinas (usa o usurio "joao" em ambas, por exemplo), pode omitir o login no comando, digitando apenas "ssh-copy-id servidor", como em: $ ssh-copy-id -i ~/.ssh/id_rsa.pub 192.168.0.1 A partir da, ao invs de pedir sua senha, o servidor envia um "desafio" encriptado usando a chave pblica. Para respond-lo, o cliente SSH na sua mquina precisa usar a chave privada, que por sua vez precisa ser destravada usando a passphrase. Mesmo que algum consiga roubar sua chave privada, no conseguir conectar sem saber a passphrase e vice-versa. Em resumo, o que o ssh-copy-id faz nada mais do que copiar o contedo do arquivo ".ssh/id_rsa.pub", dentro do seu diretrio home, para o arquivo ".ssh/authorized_keys" dentro do diretrio home do servidor remoto, uma operao que tambm pode ser realizada manualmente em caso de problemas. O arquivo ".ssh/id_rsa.pub" composto por uma nica (e longa) linha, que contm sua chave pblica de encriptao. Ela segue este padro: ssh-rsa AAAA(muitos caracteres)6lYzxBpu6M3Moe4HXaTs= login@nomedamaquina" Voc pode instalar a chave manualmente simplesmente logando-se na mquina remota via SSH e copiando a linha para dentro do arquivo ".ssh/authorized_keys", o que pode ser feito copiando e colando o texto atravs de qualquer editor que suporte esta funo, como o joe ou o vi. No final, o arquivo ".ssh/authorized_keys" da mquina remota (dentro do home) ter o mesmo contedo do arquivo ".ssh/id_rsa.pub" da sua mquina, o que orienta o servidor remoto a passar a checar sua chave privada e a passphrase, ao invs de pedir senha. Concluindo, depois de gerar a chave e conseguir se conectar atravs dela, voc pode desativar a possibilidade de fazer logins normais, usando senha. Nesse caso, apenas voc, que possui a chave gerada, conseguir se conectar ao servidor. Outras pessoas, mesmo que descubram a senha de alguma das contas, no tero como se conectar e nem como instalar uma nova chave para faz-lo, a menos que tenham acesso fsico ao servidor, a fim de copiar a chave manualmente. Isso significa que, mesmo algum com a senha de root do seu servidor em mos no conseguir fazer nada remotamente (o sonho de todo administrador ;). Isso pode ser usado para incrementar a segurana. Para isso, mude as opes "PasswordAuthentication" e "UsePAM" para "no" no arquivo "/etc/ssh/sshd_config" do servidor:

PasswordAuthentication no UsePAM no A opo "PasswordAutentication no" permite desativar o uso das senhas, como esperado, enquanto a "UsePAM no" refora a configurao, desativando qualquer outra forma de autenticao com exceo das chaves. Para que as alteraes entrem em vigor, reinicie o servidor SSH: # /etc/init.d/ssh restart ou: # service sshd restart

Transferncias SSH O SSH um verdadeiro canivete suo. Alm de permitir rodar aplicativos e fazer toda a administrao de um servidor remotamente, ele tambm pode ser usado para transferir arquivos. A forma mais bsica de fazer isso usar o sftp, um pequeno utilitrio que faz parte do pacote padro. Ele oferece uma interface similar dos antigos programas de FTP de modo texto, mas todos os arquivos transferidos atravs dele trafegam atravs de um tnel encriptado, criado atravs do SSH. Na prtica, temos uma espcie de VPN temporria, criada no momento em que efetuada a conexo. A melhor parte que o prprio SSH cuida de tudo, no necessrio instalar nenhum programa adicional. Para se conectar a um servidor usando o sftp, o comando : $ sftp usuario@servidor Se o servidor ssh na outra ponta estiver configurado para escutar em uma porta diferente da 22, preciso indicar a porta no comando, incluindo o parmetro "-o port=", como em: $ sftp -o port=2222 morimoto@gdhpress.com.br A partir da, voc tem o prompt do sftp. Use o comando "put" para dar upload de um arquivo e "get" para baixar um arquivo do servidor para a pasta local. Para navegar entre as pastas do servidor, use os comandos "cd pasta/" (para acessar a pasta), "cd .." (para subir um diretrio), "ls" (para listar os arquivos) e "pwd" (para ver em qual diretrio est). Veja um exemplo: morimoto@athenas:~$ sftp -o port=2222 morimoto@gdhpress.com.br Connecting to gdhpress.com.br... Password: ******** sftp> ls gdhpress.tar.gz www sftp> get gdhpress.tar.gz Fetching /home/morimoto/gdhpress.tar.gz togdhpress.tar.gz

/home/morimoto/gdhpress.tar.gz 100% 523MB 945.1KB/s 09:13 sftp> put backupdb.gz Uploading backupdb.gz to /home/morimoto/ backupdb.gz backupdb.gz 100% 98MB 967KB/s 01:43 sftp> pwd Remote working directory: /home/morimoto Voc pode estar se perguntando como consegui taxas de transferncia de quase 1 MB/s tanto para download quanto para upload. O segredo aqui que no estou transferindo os arquivos de um servidor remoto para meu micro de trabalho, mas sim transferindo diretamente entre dois servidores remotos, onde me loguei no primeiro via SSH e abri a conexo com o segundo a partir dele. Se os dois servidores esto ligados a portas de 10 megabits e existir uma boa conectividade entre eles, taxas de at 1 MB/s so perfeitamente normais. Se voc pagar um pouco a mais para ter portas de 100 megabits, ento possvel conseguir taxas 10 vezes maiores. :) Voltando ao sftp, existem ainda os comandos "lcd" (local cd), "lls" (local ls), "lmkdir" (local mkdir) e "lpwd" (local pwd), que permitem mudar o diretrio local. Digamos, por exemplo, que voc est atualmente no diretrio "/mnt/arquivos". Ao abrir a conexo via sftp, tudo que voc baixar ser colocado automaticamente neste diretrio. Mas, digamos que voc queira baixar um determinado arquivo para o diretrio "/home/joao". Voc usaria, ento, o comando "lcd /home/joao" para mudar o diretrio local e depois o "get arquivo" para baix-lo j na pasta correta. Na hora de dar upload de um arquivo a mesma coisa. Voc pode usar o "lls" para listar os arquivos no diretrio local e depois o "put arquivo" para dar upload. Naturalmente, existem meios mais prticos de transferir os arquivos, usando programas grficos que suportam o sftp. O dois mais usados so o prprio Konqueror (no KDE) e o Nautilus (no Gnome), que alm de serem gerenciadores de arquivos, suportam o uso de diversos protocolos de transferncia, incluindo o sftp. No Konqueror, digite "fish://", seguido pelo login e o endereo do servidor (separados por uma arroba) na barra de endereos, como em "fish://gdh@gdhn.com.br". Ele exibe uma janela grfica pedindo a confirmao da identidade do servidor (apenas na primeira conexo) e em seguida outra, solicitando a senha. Depois de estabelecida a conexo, voc tem acesso direto aos arquivos do servidor, dentro das permisses da sua conta de usurio. Voc pode tambm especificar diretamente uma pasta no servidor remoto que quer acessar (por padro voc cai na pasta home), como em "fish://gdh@gdhn.com.br/home/revista/". Para tornar as coisas mais prticas, eu uso o recurso de dividir a janela em duas, que voc encontra no "Janela > Separar viso em topo/base". Assim, fico com uma janela mostrando os arquivos locais e outra mostrando os arquivos do servidor, e posso simplesmente arrastar os arquivos que devem ser transferidos:

O Konqueror no muito bom em prever erros com a conexo, se limitando a exibir um "no possvel se conectar ao servidor". Nesses casos, abra um terminal e experimente tentar se conectar via texto para ver as mensagens de erro e poder assim diagnosticar o problema. No Nautilus, clique em "Arquivo > Conectar ao servidor". Na janela seguinte, escolha "SSH" na opo "Tipo de servio" e fornea o endereo do servidor e o login que ser usado, no campo "Nome do Usurio". O campo com a pasta permite especificar qual pasta ser acessada por padro ao efetuar a conexo, mas ela opcional. O campo "Porta" usado apenas caso voc tenha configurado o servidor SSH para escutar em uma porta diferente da 22:

Isso cria um cone de acesso, que aparece tanto no desktop quanto na barra "Locais" do Nautilus. Para finalmente efetuar o acesso, clique sobre o cone e fornea a senha. A grande limitao do sftp (e das interfaces grficas para ele) que ele exige interveno manual e, por isso, no adequado para uso em scripts para realizar transferncias automatizadas (como no caso de um script de backup). Para isso, temos o "scp", um cliente ainda mais primitivo, que permite especificar em uma nica linha o login e endereo do servidor, junto com o arquivo que ser transferido. A sintaxe do scp : "scp arquivo_local login@servidor:pasta_remota", como em: $ scp /home/gdh/arquivo.tar gdh@gdhn.com.br:/var/www/download Voc pode adicionar tambm as opes "-p" (que preserva as permisses de acesso alm das datas de criao e modificao do arquivo original), "-r" (que permite copiar

pastas, recursivamente), "-v" (verbose, onde so mostradas todas as mensagens) e "-C" (que ativa a compresso dos dados, ajudando muito na hora de transferir grandes arquivos via Internet). Nesse caso, o comando ficaria: $ scp -prvC /home/gdh/arquivo.tar gdh@gdhn.com.br:/var/www/download Ao incluir a opo "-r", voc pode especificar diretamente uma pasta no primeiro parmetro, o que faz com que todo o seu contedo seja transferido. Esta opo interessante para backups. O SSH pode ser ainda usado como "meio de transporte" por outros programas, como no caso do rsync, um utilitrio que permite sincronizar uma pasta local com uma pasta do servidor. Ele capaz de fazer uma cpia diferencial, transferindo apenas os trechos dos arquivos que foram modificados o que o torna um utilitrio quase que ideal para backup de pastas com um grande volume de arquivos. Ele capaz inclusive de consertar arquivos danificados e dar upload de atualizaes, enviando apenas as partes dos arquivos que forem diferentes, o que torna a transferncia muito mais rpida. O uso bsico do rsync, para sincronizar duas pastas locais, seria "rsync -a origem/ destino/". A pasta destino poderia ser um segundo HD, um carto de memria ou um compartilhamento de rede, por exemplo. Usado dessa forma, o rsync serve apenas para fazer backups locais, mas, ao combin-lo com o SSH, abrimos uma nova gama de possibilidades. Para usar o rsync via SSH, o comando acaba sendo bem mais complexo, mas o resultado bem interessante. Ele vai apenas atualizar as partes dos arquivos remotos que foram modificados, sem dar upload dos arquivos inteiros novamente, como muitos programas de backup fariam. Para sincronizar a pasta local "/home/gdh" com a pasta remota "/backup", no servidor "gdhn.com.br" (onde seria feito um backup dos arquivos locais), usando o login "gdh", por exemplo, o comando seria: $ rsync -av --rsh="ssh -l gdh" /home/gdh/ gdh@gdhn.com.br:/backup Para recuperar posteriormente o backup no caso de um desastre, baixando os arquivos salvos no servidor, bastaria inverter a ordem dos diretrios no comando, como em: $ rsync -av --rsh="ssh -l gdh" gdh@gdhn.com.br:/backup /home/gdh/ No primeiro comando os arquivos da pasta "/home/gdh" vo para a pasta /backup do servidor e no segundo eles so recuperados, subscrevendo os arquivos locais. A parte mais significativa deste comando o parmetro "--rsh="ssh -l gdh", que diz para o rsync usar um programa externo (o SSH) para fazer o trabalho. Uma observao que usando apenas os parmetros "-av", o rsync apenas atualiza e grava novos arquivos na pasta do servidor, sem remover arquivos que tenham sido deletados na pasta local. Por um lado isso bom, pois permite recuperar arquivos deletados acidentalmente, mas por outro pode causar confuso. Se voc preferir que os arquivos que no existem mais sejam deletados ao atualizar o backup, adicione o parmetro "--delete", como em: $ rsync -av --delete --rsh="ssh -l gdh" /home/gdh/ gdh@gdhn.com.br:/backup O rsync no vem instalado por padro na maioria das distribuies, mas pode ser instalado rapidamente usando o gerenciador de pacotes, como em:

# apt-get install rsync

Tuneis Seguros
Uma forma simples de encriptar protocolos que em condies normais no suportam encriptao usar o SSH para criar tneis seguros, ligando uma das portas da sua mquina porta do servidor onde o servio em questo est ativo. Nesse caso, criada uma espcie de VPN temporria, atravs da qual possvel acessar o servio de forma segura. Todas as informaes transmitidas so encriptadas pelo SSH, tornando seguros mesmo protocolos "escancarados", como o Telnet e o FTP. Um dos usos mais comuns para este recurso encriptar sesses do VNC, evitando que pessoas mal intencionadas tenham acesso ao que foi feito dentro da sesso, mesmo que ela seja interceptada. O VNC utiliza uma chave de encriptao de mo nica durante a autenticao, de forma que a senha no circula abertamente pela rede. Isso impede que algum sniffando a rede consiga capturar sua senha do VNC, como acontece no caso do Telnet, por exemplo. Apesar disso, o algoritmo de encriptao de senha usado pelo VNC no muito seguro e, depois que a conexo iniciada, os dados so enviados de forma no-encriptada, abrindo a possibilidade de que algum capaz de capturar os pacotes transmitidos possa ver o que voc est fazendo e at mesmo capturar as teclas digitadas no teclado. Se voc utiliza o VNC para tarefas sensveis, como administrar servidores, acessar sistemas bancrios, etc., pode implantar uma camada extra de segurana, utilizando o VNC em conjunto com o SSH. Nesse caso, a segurana quase total, pois alm de ser necessria uma dupla autenticao (primeiro no SSH e depois no VNC), todos os dados so transmitidos atravs da rede de forma encriptada, utilizando um algoritmo reconhecidamente seguro. Para utilizar o SSH em conjunto com o VNC, utilizamos a opo "-L", que permite redirecionar uma determinada porta local para uma porta no servidor, criando o tnel. A sintaxe do SSH, neste caso, seria "ssh -L porta_local:servidor:porta_do_servidor servidor". Parece complicado, mas vai melhorar... :) O servidor VNC escuta na porta 5900 + o nmero do display (5901, 5902, 5903, etc.). Note que a porta diferente do servidor Java, acessvel utilizando o browser, que utiliza as portas de 5800 em diante. Se voc vai acessar o display 1 (porta 5901), na mquina 220.132.54.78, precisamos orientar o SSH a redirecionar esta porta para uma porta acessvel pelo cliente VNC (a prpria porta 5901, ou qualquer outra) no PC local. Para isso, necessrio que o servidor SSH esteja aberto no servidor remoto e que voc tenha uma conta nele. O comando seria: $ ssh -f -N -L5901:220.132.54.78:5901 -l login 220.132.54.78 Substitua o "login" pela sua conta de usurio na mquina remota. O SSH pedir a senha (ou passphrase) e, pronto, o tnel estar criado. Tudo o que voc precisa fazer agora abrir o cliente VNC e acessar o endereo "127.0.0.1:1". Isso far com que o cliente acesse a porta 5901 na mquina local, que por sua vez ser redirecionada (atravs do tnel) para a porta 5901 do servidor remoto. Voc usar o VNC da mesma forma, mas desta vez usando um tnel seguro. Se por acaso a porta 5901 local j estiver em uso, voc pode simplesmente criar o tnel apontando para outra porta da sua mquina. Se voc fosse acessar o display 4 (porta

5904) no servidor 192.168.0.4, redirecionando-o para a porta 5905 (display 5) da mquina local, logando-se usando o usurio "tux", o comando seria: $ ssh -f -N -L5905:192.168.0.4:5904 -l tux 192.168.0.4 Nesse caso, voc acessaria o endereo "127.0.0.1:5" no cliente VNC, que faz com que ele se conecte na porta 5905. A desvantagem de utilizar o SSH em vez de acessar o servidor VNC diretamente que a atualizao de tela ficar um pouco mais lenta, pois o servidor ter dois trabalhos, o de compactar os dados usando um dos algoritmos do VNC e, em seguida, encriptar os pacotes usando a chave do SSH, uma dupla jornada. Entretanto, se pensarmos do ponto de vista da segurana, a troca acaba sendo vantajosa. Alm do VNC, este comando pode ser usado para criar tneis para outras portas. Para redirecionar portas privilegiadas, da 1 a 1024, voc precisa executar o comando como root. Para as portas altas (como as usadas pelo VNC), voc pode usar um login normal de usurio. O parmetro "-f" dentro do comando faz com que ele seja executado em background, liberando o terminal depois que a conexo estabelecida. O "-N" faz com que o SSH apenas crie o redirecionamento da porta, sem abrir um terminal do servidor remoto, enquanto o "-L" a opo principal, que especifica que queremos fazer um redirecionamento de portas. Ele seguido (sem espaos) pela porta local que receber a porta remota, o endereo do servidor e a porta do servidor que ser redirecionada ("L2525:192.168.0.4:25" redireciona a porta 25 do servidor remoto para a porta 2525 da mquina local). Concluindo, o "-l" em seguida especifica o login que ser usado para estabelecer a conexo, seguido pelo endereo IP do servidor. Em resumo, a sintaxe deste longo comando "ssh -f -N -Lporta-local:servidor:porta-doservidor -l login servidor" (veja que necessrio especificar o endereo do servidor remoto duas vezes). Seja qual for a porta destino, todo o trfego transportado atravs da porta do SSH e encaminhada localmente para a porta final. Graas a essa peculiaridade, os tneis so uma forma muito usada para acessar ferramentas como o Webmin, phpMyAdmin ou Swat em servidores remotos, sem precisar manter as respectivas portas abertas para toda a Internet. Basta que a porta 22 (ou outra em que o servidor SSH esteja escutando) esteja aberta para que voc consiga acessar qualquer outra usando tneis. Em casos em que o servidor remoto esteja configurado para usar uma porta diferente da padro para o SSH, adicione a opo "-p porta" no incio do comando, como em: # ssh -p 2222 -f -N -L901:gdhn.com.br:901 -l login gdhn.com.br Continuando, um segundo exemplo interessante de uso seria usar um tnel para encriptar todo o trfego web, de forma que voc possa navegar de forma segura, ler seus e-mails, etc. mesmo ao acessar atravs de uma conexo wireless sem qualquer tipo de encriptao. Para isso, preciso que o gateway da rede (ou alguma mquina na Internet, que seja acessvel por voc) esteja com um servidor proxy aberto (se voc estiver usando o Squid, por exemplo, o proxy ficar aberto na porta 3128 do servidor). Podemos usar ento o SSH para criar um tnel, ligando a porta 3128 do servidor porta 3128 (ou qualquer outra) do seu micro, como em: $ ssh -f -N -L3128:gdhn.com.br:3128 -l tux gdhn.com.br

O prximo passo configurar o navegador na sua mquina para acessar usando o proxy. Entretanto, em vez de configurar o navegador para acessar o proxy diretamente, vamos configur-lo para procurar o proxy na porta 3128 do localhost. Isso faz com que todos os acessos sejam direcionados ao tnel criado atravs do SSH e cheguem at o proxy de forma encriptada:

Para ser usado dessa forma, o proxy rodando no servidor remoto deve ser configurado para aceitar conexes de qualquer cliente, j que mesmo passando pelo tnel, o acesso ser computado pelo Squid como partindo do seu IP de Internet atual. Um exemplo de configurao do Squid para que o servidor permitisse a conexo de qualquer cliente remoto seria: http_port 3128 visible_hostname gdh acl all src 0.0.0.0/0.0.0.0 acl manager proto cache_object acl localhost src 127.0.0.1 acl SSL_ports port 443 563 acl Safe_ports port 21 80 443 563 70 210 280 488 59 777 901 1025-65535 acl purge method PURGE acl CONNECT method CONNECT http_access allow manager localhost http_access deny manager http_access allow purge localhost http_access deny purge http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access allow all

Como voc pode ver essa configurao simplesmente permite acessos provenientes de qualquer endereo. O truque que como o servidor ser acessado atravs dos tneis criados usando o SSH, voc pode manter a porta 3128 fechada no firewall do servidor, permitindo apenas conexes atravs da porta 22. Com isso, o servidor no ficar vulnervel, j que a nica forma de chegar at o proxy criando um tnel at ele atravs do SSH.

Tambm tem a possibilidade de criao no Windows mais no sei como configurar.