Trabalho de Redes: SSH

Aluno: Rogério Magno da Silva Rodrigues

Sistemas de Informação 7º “B”

Faculdade Fortium

Protocolo SSH

Protocolo SSH

O protocolo de rede SSH foi criado para permitir conexões seguras entre máquinas e permitir a execução de comandos remotos de shell. Aliás, é daí que deriva o nome deste protocolo.

SSH vem de Secure SHell. Antes deste protocolo usava-se o Telnet e o RLogin, que também permitem fazer login num computador multi-usuário através de uma máquina remota que esteja na mesma rede. Acontece que o tráfego IP normal possui as seguintes fraquezas que podem ser exploradas para comprometer a segurança:

Autenticação deficiente baseada em endereços 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 proteção de integridade porque as conexões podem ser sequestradas

(hijacked}.

O SSH foi projetado para eliminar estes problemas oferecendo um mecanismo de autenticação mais robusto para identificar tanto as máquinas quanto os usuários e para assegurar conexões seguras. Este protocolo pode substituir as funções do RSH, do RCP e do RLogin e, em muitos casos, também pode substituir o Telnet e o FTP, além de expandir outras conexões (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, Finlândia. Após um incidente de segurança na universidade, Ylonen criou a tecnologia da Secure Shell para criptografar os dados transmitidos em redes TCP/IP. A primeira versão recebeu o nome de SSH1. Em 2006, a sétima versão do SSH foi aceita como padrão pela IETF, adquirindo o status de tecnologia padrão junto com o HTTP, TCP e IP.

Sistemas operacionais multi-usuário, 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 disponível). Mas nem tudo precisa ser feito "na unha". Existem interfaces gráficas excelentes para fazer este tipo de conexão segura. Dois exemplos são o PuTTY e o WinSCP (costumo usar os dois) que você encontra na seção de downloads da Aldeia. Procure em Informática/Shell.

O SSH foi projetado para fornecer autenticação e comunicação seguras através de canais inseguros. Permite logins, execução de comandos e cópias remotas substituindo o RLogin, RSH, RCP e RDist. Possui as seguintes características:

Agentes de autenticação podem guardar as chaves RSA de autenticação de usuário. Estes agentes rodam no laptop ou máquina local do usuário e não há necessidade de guardar as chaves de autenticação RSA em outro local. O SSH transfere automaticamente a conexão para o agente de autenticação, nunca revelando as chaves. Os protocolos são usados apenas para verificar se o agente possui a chave do usuário.

O cliente possui arquivos de configuração customizáveis, tanto para o sistema quanto por usuário. Opções diferentes podem ser especificadas para hosts diferentes.

Se a máquina servidora não estiver rodando sshd, um aviso de alerta é mostrado e o ssh automaticamente retrocede para usar o rsh convencional.

A compressão gzip de todos os dados, incluindo X11 redespachado e dados de portas TCP/IP, é opcional.

Administração 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 conexões de terminais baseadas em Telnet entre estações de trabalho Windows e servidores Unix/Linux/Windows. O principal grupo de usuários de acessos seguros de terminais são administradores de sistema, que adotaram o Secure Shell como padrão de-facto na administração remota de servidores Unix e outros dispositivos de rede.

Conectividade Segura de Aplicações

O Secure Shell disponibiliza dois modos diferentes de proteger conexões de aplicações entre estações de trabalho de usuários finais e servidores de aplicação. Em aplicações 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" conexões TCP de aplicações sem a necessidade de substituir o programa e a interface do usuário. A capacidade de redirecionamento de portas faz do Secure Shell uma solução genérica para proteger do começo ao fim conexões de protocolos de aplicações.

Entendendo SSH

O SSH permite administrar máquinas remotamente (executando tanto comandos em modo texto quanto aplicativos gráficos), permite transferir arquivos de várias formas diferentes e, como se não bastasse, permite também encapsular outros protocolos, permitindo, por exemplo, acessar uma sessão do VNC através de um túnel seguro.

A grande vantagem do SSH sobre outras ferramentas de acesso remoto é a grande ênfase na segurança. Um servidor SSH bem configurado é virtualmente impenetrável e você pode acessá-lo de forma segura, mesmo que a sua rede local esteja comprometida. Ele utiliza um conjunto de técnicas de criptografia para assegurar que apenas as pessoas autorizadas tenham acesso ao servidor, que todos os dados transmitidos sejam impossíveis de decifrar e que a integridade da conexão seja mantida.

São previstas respostas para diversos tipos de ataques conhecidos. O SSH detecta casos em que o servidor tenha sido substituído por outra máquina, situações nas quais se tenta injetar dados na conexão (ou seja, tirar proveito de uma conexão aberta para incluir pacotes com comandos adicionais) e inclui até mesmo técnicas 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 força bruta.

A idéia central é que, mesmo em situações onde seja fácil interceptar a transmissão (como no caso de uma rede wireless pública), seja impossível descobrir o conteúdo dos pacotes, devido à encriptação. É possível ainda, utilizar um par de chaves em vez de uma senha como forma de autenticação. Nesse caso, além 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 difícil de adivinhar.

Você poderia argumentar que qualquer algoritmo de encriptação pode ser quebrado via força bruta (onde simplesmente são testadas todas as possibilidades possíveis, até encontrar a combinação correta), de forma que nenhum sistema de encriptação é inteiramente seguro. Entretanto, ataques de força bruta só são realmente viáveis contra chaves de 40 ou 64 bits; acima disso é inviável, 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 considerável de transmissões usando um sniffer (um programa que captura a transmissão 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 máquinas com processadores Xeon ou Opteron quad-core.

Uma chave de 64 bits é cerca de 16 milhões de vezes mais difícil de quebrar via força 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 necessários à disposição, mas uma de 128 (sem brechas conhecidas) é impossível de quebrar com tecnologia atual.

O perigo no caso dos algoritmos de encriptação não são propriamente os ataques de força bruta (que exigem muito tempo e recursos), mas sim falhas que permitam descobrir a chave usada em menos tempo. As versões originais do WEP (o sistema de encriptação 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 encriptação dos DVDs, que é quebrado em poucos segundos por uma máquina atual, utilizando um algoritmo de poucas linhas.

Felizmente, este não é 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 código é exaustivamente auditado por uma variedade de empresas e órgãos governamentais.

O SSH utiliza chaves assimétricas para fazer a autenticação. As chaves assimétricas são um sistema muito interessante, onde temos um par de chaves em vez de uma única chave simétrica. Uma (a chave pública), permite apenas encriptar dados, enquanto a segunda (a chave privada) permite desencriptar as informações embaralhadas pela primeira. O grande segredo é que qualquer informação embaralhada usando a chave pública pode ser recuperada apenas usando a chave privada correspondente. Como o nome sugere, a chave pública pode ser distribuída 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 públicas, permitindo que um envie informações para o outro de forma segura. Através deste canal inicial é feita a autenticação, 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 configuração). O problema é que, embora virtualmente impossível de quebrar, este nível de encriptação demanda um volume muito grande de processamento. Se todas as informações fossem transmitidas desta forma, o SSH seria muito lento.

Para solucionar este problema, depois de fazer a autenticação, o SSH passa a utilizar um algoritmo mais simples (que demanda muito menos processamento) para transmitir os dados. Por padrão é utilizado o 3DES (triple-DES), que utiliza uma combinação de três chaves DES, de 64 bits cada. As chaves são trocadas periodicamente durante a conexão, o que torna o sistema quase impossível de quebrar. Na configuração do servidor e/ou cliente, é possível especificar outro algoritmo, como o Blowfish. Isso garante uma boa relação entre segurança e desempenho.

O SSH é dividido em dois módulos. O sshd é o módulo servidor, um serviço que fica residente na máquina que será acessada, enquanto ossh é o módulo cliente, um utilitário 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 instalação em modo servidor do sistema o SSH será instalado e configurado para subir no boot automaticamente, mas, de qualquer forma, não custa verificar. Nas distribuições derivadas do Debian, ele é ativado usando o serviço "ssh", como em:

# /etc/init.d/ssh start

Nas derivadas do Red Hat, incluindo o Mandriva e o CentOS o serviço se chama sshd:

# service sshd start

No caso do CentOS, você precisa usar o comando "chkconfig sshd on" para ativar a inicialização automática do serviço caso o pacote seja instalado depois da instalação do sistema:

# chkconfig sshd on

Como de praxe, é necessário manter a porta 22 usada pelo SSH aberta no firewall do servidor. O SSH permite fazer quase tudo através dessa única porta, atendendo a diversos clientes simultâneos.

Concluindo, para usar o SSH no seu micro de trabalho é necessário ter instalado apenas o pacote "openssh-client". Veja que o cliente e o servidor são intencionalmente mantidos em pacotes separados justamente para permitir que você instale apenas um ou outro conforme necessário.

A configuração do servidor, independentemente da distribuição usada, vai no arquivo "/etc/ssh/sshd_config", enquanto a configuração do cliente vai no "/etc/ssh/ssh_config". Note que muda apenas um "d" entre os dois; cuidado para não confundir cará com batata doce. ;)

Outra observação é que além do OpenSSH, que abordo aqui, existem outras versões do SSH, como o Tectia (uma versão comercial, disponível no http://ssh.com) e o SunSSH que, embora conservem diferenças no funcionamento e na configuração, são compatíveis entre si. O SSH é, na verdade, um protocolo aberto e não o nome de uma solução específica.

O uso básico 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 é tão rico em funções que até mesmo os administradores mais experientes raramente usam mais do que um punhado das funções disponíveis. Vamos então a uma visão mais aprofundada do SSH, começando com dicas de configuração:

Configuração do Cliente SSH

Ao ser ativado, o padrão do servidor SSH é permitir acesso usando qualquer uma das contas de usuário 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 também especificar o login usando o parâmetro "-l" (de login), como em:

$ ssh -l morimoto 192.168.0.2

Você pode também acessar o servidor usando o domínio, como em:

$ ssh morimoto@gdhpress.com.br

Caso você omita o nome do usuário, o SSH presume que você quer acessar usando o mesmo login que está utilizando na máquina 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 máquinas.

Ao acessar micros dentro da rede local, você pode também chamá-los pelo nome, como em "ssh morimoto@servidor". Neste caso, você precisará primeiro editar o arquivo "/etc/hosts" (no cliente), incluindo os números de IP das máquinas e os nomes correspondentes. O formato deste arquivo é bem simples, basta fornecer o IP e o nome da máquina correspondente, um por linha, como em:

127.0.0.1 localhost192.168.0.2 servidor192.168.0.6 athenas

A configuração do arquivo "/etc/hosts" vale apenas para a sua própria máquina, ele nada mais é do que um arquivo com aliases. Se você quiser que os apelidos sejam válidos também para as demais máquinas da rede, a melhor opção é configurar um servidor DNS de rede local.

Voltando à configuração do SSH, vamos a algumas opções importantes dentro da configuração do cliente SSH, que vão no arquivo "/etc/ssh/ssh_config":

Aplicativos gráficos: Além de oferecer acesso via linha de comando, o SSH permite rodar aplicativos gráficos remotamente (X11 forwarding). Muitas distribuições trazem o recurso desabilitado por padrão. Nestes casos, edite o arquivo "/etc/ssh/ssh_config" (no cliente) e substitua a linha "ForwardX11 no" por:

ForwardX11 yes

Outra opção é adicionar o parâmetro "-X" ao se conectar, como em "ssh -X tux@192.168.0.1". A partir daí, você pode chamar os aplicativos gráficos normalmente, como se estivesse usando um terminal local.

O maior problema com o uso de aplicativos gráficos via SSH é que ele só funciona satisfatoriamente dentro da rede local. Via Internet os aplicativos gráficos ficam realmente muito lentos (mesmo em uma conexão 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 próprio servidor.

Para rodar aplicativos gráficos de forma segura via Internet, a melhor solução é 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 conexões via modem.

Compressão: No caso de servidores acessíveis via Internet, você pode reduzir um pouco o consumo de banda ativando a compressão de dados via gzip, o que é feito adicionado a linha:

Compression = yes

Você pode também ativar a compressão adicionando a opção "-C" na hora de se conectar. Quase todas as opções do cliente SSH podem ser especificadas tanto no arquivo, quanto via linha de comando.

Keep Alive: Outro problema comum relacionado ao SSH é a conexão ser fechada pelo servidor depois de alguns minutos de inatividade. Em muitas situações você quer manter a conexão aberta por longos períodos, sem precisar ficar dando um "ls" ou um "pwd" a cada dois minutos para manter a conexão aberta.

Você pode evitar o problema fazendo com que o próprio cliente mande pacotes periodicamente a fim de manter a conexão aberta. Para ativar o recurso, adicione a opção "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 opções que vimos até aqui (excluindo os comentários):

ForwardX11 yesCompression = yes

Port 22ServerAliveInterval 120

Como em outros arquivos de configuração, você não precisa se preocupar em incluir cada uma das opções disponíveis, pois o SSH simplesmente usa os valores default para as opções não incluídas no arquivo. Com isso, você precisa se preocupar apenas com as opções que conhece, omitindo as demais.

Verificação do servidor: Como parte das verificações de segurança, o SSH utiliza também um sistema baseado em chaves assimétricas para verificar a identidade do servidor. O servidor possui uma chave pública, que é enviada ao cliente na primeira conexão. As identificações de todos os servidores conhecidos ficam armazenadas no arquivo ".ssh/known_hosts", dentro do seu diretório home. Sempre que você se conecta daí em diante, o cliente SSH envia um "desafio" ao servidor, uma frase encriptada usando a chave pública (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 "intermediário", ou "impostor"), em que alguém simplesmente substitui o servidor por outra máquina, 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 domínio.

O servidor falso pode ser configurado para gravar sua senha e responder com uma mensagem do tipo "O servidor está em manutenção, tente novamente daqui a algumas horas". Dessa forma, ele vai ter não 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 identificação do servidor mudou e lhe avisa do problema:

Para continuar é preciso que você remova a linha com a identificação do servidor salva no arquivo .ssh/know_hosts, dentro do diretório home do usuário que está utilizando. Isso pode ser feito de duas formas.

A primeira é remover a chave usando o comando "ssh-keygen -R", seguido pelo endereço IP ou o domínio 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 edição manual do arquivo, removendo a linha correspondente ao servidor e salvando um backup do arquivo original por precaução.

A segunda opção é 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, começando com o endereço IP ou o nome de domínio usado no acesso.

Em qualquer um dos dois casos, da próxima vez que tentar se conectar, o SSH exibe uma mensagem mais simpática, 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)?

Não existe forma de fazer com que o cliente SSH adicione as novas chaves automaticamente, isso seria uma brecha de segurança. É sempre preciso primeiro remover a chave antiga manualmente.

As chaves de identificação são geradas durante a instalação do SSH e salvas nos arquivos "/etc/ssh/ssh_host_rsa_key" e "/etc/ssh/ssh_host_dsa_key" (no servidor). Para não disparar o alarme nos clientes quando precisar reinstalar o sistema no servidor, ou quando substituí-lo por outra máquina, salve os dois arquivos em um pendrive e restaure-os depois da instalação. Você pode fazer isso mesmo ao migrar para outra distribuição, pois as localizações dos dois arquivos não mudam.

Uma última opção seria desabilitar a checagem das chaves, adicionando a opção "StrictHostKeyChecking no" na configuração dos clientes. Contudo, isso não é recomendável, pois desabilita completamente a checagem, abrindo brechas para ataques.

Configuração do Servidor SSH

Você pode configurar várias opções relacionadas ao servidor SSH, incluindo a porta TCP a ser usada editando o arquivo "/etc/ssh/sshd_config". Assim como no caso da configuração do cliente, a maior parte das opções dentro do arquivo podem ser omitidas (pois o servidor simplesmente utiliza valores default para as opções que não constarem no arquivo), mas, de qualquer forma, é saudável especificar todas as opções que conhece: além de evitar enganos, é uma forma de praticar e memorizar as opções.

Porta: Uma das primeiras linhas é a:

Port 22

Esta é a porta que será usada pelo servidor SSH. O padrão é usar a porta 22. Ao mudar a porta do servidor aqui, você deverá usar a opção "-p" ao conectar a partir dos clientes para indicar a porta usada, como em:

# ssh -p 2222 morimoto@gdhn.com.br

Outra opção é editar o arquivo "/etc/ssh/ssh_config" (nos clientes) e alterar a porta padrão usada por eles. Mudar a porta padrão do SSH é uma boa idéia se você está preocupado com a segurança. Muitos dos ataques "casuais" (quando o atacante simplesmente varre faixas inteiras de endereços, sem um alvo definido), começam com um portscan genérico, onde é feita uma varredura em faixas inteiras de endereços IP, procurando por servidores com portas conhecidas abertas, como a 21, a 22 e a 80. Isso torna o teste mais rápido, permitindo localizar rapidamente um grande volume de hosts com portas abertas. A partir daí, os ataques vão sendo refinados e direcionados apenas para os servidores vulneráveis encontrados na primeira varredura. Colocar seu servidor para escutar uma porta mais escondida, algo improvável como a porta 32456 ou a 54232 reduz sua exposição.

Controle de acesso: Logo abaixo vem a opção "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 típico caso em que você quer que o SSH fique acessível apenas na rede local, mas não na Internet, por exemplo. Digamos que o servidor use o endereço "192.168.0.1" na rede local e você queira que o servidor SSH não fique disponível na Internet. Você adicionaria a linha:

ListenAddress 192.168.0.1

Note que especificamos nesta opção o próprio IP do servidor na interface escolhida, não a faixa de IP's da rede local ou os endereços que terão acesso a ele.

Protocolo: Atualmente utilizamos o SSH 2, mas ainda existem alguns poucos clientes que utilizam a primeira versão do protocolo. Por padrão, o servidor SSH aceita

conexões 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 segurança, por isso é recomendável desativar a compatibilidade com ele, aceitando apenas clientes que usam o SSH 2. Neste caso, a linha fica apenas:

Protocol 2

Restringir a versão do protocolo ajuda a melhorar a segurança, pois evita que usuários 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 encriptação. Desativando a compatibilidade com o SSH 1 você corta o mal pela raiz.

Usuários e senhas: Outra opção interessante, geralmente colocada logo abaixo, é a:

PermitRootLogin yes

Esta opção determina se o servidor aceitará que usuários se loguem como root. Do ponto de vista da segurança, é melhor deixar esta opção como "no", pois assim o usuário 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 invés 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 padrão, o SSH permite que qualquer usuário cadastrado no sistema se logue remotamente, mas você pode refinar isso através da opção "AllowUsers", que especifica uma lista de usuários que podem usar o SSH. Quem não estiver na lista, continua usando o sistema localmente, mas não consegue se logar via SSH. Isso evita que contas com senhas fracas, usadas por usuários que não têm necessidade de acessar o servidor remotamente coloquem a segurança do sistema em risco. Para permitir que apenas os usuários "joao" e "maria" possam usar o SSH, por exemplo, adicione a linha:

AllowUsers joao maria

Você pode ainda inverter a lógica, usando a opção "DenyUsers". Neste caso, todos os usuários cadastrados no sistema podem fazer login, com exceção dos especificados na linha, como em:

DenyUsers ricardo manuel

Outra opção relacionada à segurança é a:

PermitEmptyPasswords no

Esta opção faz com que qualquer conta sem senha fique automaticamente desativada no SSH, evitando que alguém 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 encriptação se o usuário escreve a senha em um post-it colado no monitor, ou deixa a senha em branco.

Banner: Alguns servidores exibem mensagens de advertência antes do prompt de login, avisando que todas as tentativas de acesso estão sendo monitoradas ou coisas do gênero. A mensagem é especificada através da opção "Banner", onde você indica um arquivo de texto com o conteúdo a ser mostrado, como em:

Banner = /etc/ssh/banner.txt

X11 Forwarding: Além de ser usada na configuração dos clientes, a opção "X11Forwarding" pode ser também incluída na configuração do servidor:

X11Forwarding yes

Ela determina se o servidor permitirá que os clientes executem aplicativos gráficos remotamente. Se o servidor for acessado via Internet ou se possui um link lento, você pode deixar esta opção como "no" para economizar banda. Desta forma, os clientes poderão executar apenas comandos e aplicativos de modo texto. Note que ao usar "X11Forwarding no" o encaminhamento é recusado pelo próprio servidor, de forma que o usuário não consegue rodar aplicativos gráficos mesmo que a opção esteja ativa na configuração do cliente.

- SFTP: O SSH inclui um módulo de transferência de arquivos (o SFTP), que veremos em detalhes a seguir. Ele é ativado através da linha:

Subsystem sftp /usr/lib/sftp-server

É realmente necessário que esta linha esteja presente para que o SFTP funcione. Comente esta linha apenas se você realmente deseja desativá-lo.

Atualização

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 informações pessoais ou de senhas antigas. Se você tem o hábito de usar as mesmas senhas em vários locais, a possibilidade cresce, pois muitos serviços armazenam ou transmitem senhas de formas não seguras. Com isso, as senhas acabam sendo o ponto fraco da segurança.

Como de praxe, o SSH oferece uma resposta para o problema. Em vez de depender unicamente da senha como forma de autenticação, você pode utilizar um par de chaves de autenticação, onde a chave pública é instalada nos servidores que serão acessados e a chave privada (que nunca sai da sua máquina) é protegida por uma passphrase, sem a qual a chave se torna inútil.

Nesse caso, temos uma segurança de dois níveis, em que é preciso saber a passphrase e, além dela, ter a chave privada, um arquivo salvo no HD ou em um pendrive, algo similar ao sistema bancário, onde você precisa ter o cartão 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 usuário (o mesmo que você usa para acessar os servidores remotos), não 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 não seja algo fácil de adivinhar. A passphrase é, na verdade, um componente da chave de encriptação; sem ela é impossível usar a chave.

O comando gerará os arquivos ".ssh/id_rsa" e ".ssh/id_rsa.pub" dentro do seu diretório home, que são, respectivamente, sua chave privada e sua chave pública. 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 usuários da máquina possam lê-lo.

Muitos servidores recusam a conexão caso os arquivos estejam com as permissões abertas.

Depois de gerar seu par de chaves, falta o comando final, que instala a chave pública no servidor, permitindo que ela seja usada para autenticação:

$ ssh-copy-id -i ~/.ssh/id_rsa.pub login@servidor

Como o nome sugere, o comando "ssh-copy-id" copia sua chave pública, instalando-a no servidor. Ao usá-lo, substitua o "login" pelo seu login de usuário e o "servidor" pelo endereço IP ou o domínio do servidor.

Ao ser executado, ele abrirá uma conexão via SFTP (ainda utilizando seu login e senha de acesso), que é usada para instalar a chave pública (o arquivo ".ssh/id_rsa.pub", dentro do seu home) no diretório correspondente do servidor. Naturalmente, para que a transferência funcione, é necessário que o SFTP esteja ativo na configuração do servidor.

Caso você utilize o mesmo login de usuário nas duas máquinas (usa o usuário "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 invés de pedir sua senha, o servidor envia um "desafio" encriptado usando a chave pública. Para respondê-lo, o cliente SSH na sua máquina precisa usar a chave privada, que por sua vez precisa ser destravada usando a passphrase. Mesmo que alguém consiga roubar sua chave privada, não conseguirá conectar sem saber a passphrase e vice-versa.

Em resumo, o que o ssh-copy-id faz nada mais é do que copiar o conteúdo do arquivo ".ssh/id_rsa.pub", dentro do seu diretório home, para o arquivo ".ssh/authorized_keys" dentro do diretório home do servidor remoto, uma operação que também pode ser realizada manualmente em caso de problemas.

O arquivo ".ssh/id_rsa.pub" é composto por uma única (e longa) linha, que contém sua chave pública de encriptação. Ela segue este padrão:

ssh-rsa AAAA(muitos caracteres)6lYzxBpu6M3Moe4HXaTs= login@nomedamaquina"

Você pode instalar a chave manualmente simplesmente logando-se na máquina remota via SSH e copiando a linha para dentro do arquivo ".ssh/authorized_keys", o que pode ser feito copiando e colando o texto através de qualquer editor que suporte esta função, como o joe ou o vi. No final, o arquivo ".ssh/authorized_keys" da máquina remota (dentro do home) terá o mesmo conteúdo do arquivo ".ssh/id_rsa.pub" da sua máquina,

o que orienta o servidor remoto a passar a checar sua chave privada e a passphrase, ao invés de pedir senha.

Concluindo, depois de gerar a chave e conseguir se conectar através 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, não terão como se conectar e nem como instalar uma nova chave para fazê-lo, a menos que tenham acesso físico ao servidor, a fim de copiar a chave manualmente. Isso significa que, mesmo alguém com a senha de root do seu servidor em mãos não conseguirá fazer nada remotamente (o sonho de todo administrador ;). Isso pode ser usado para incrementar a segurança.

Para isso, mude as opções "PasswordAuthentication" e "UsePAM" para "no" no arquivo "/etc/ssh/sshd_config" do servidor:

PasswordAuthentication noUsePAM no

A opção "PasswordAutentication no" permite desativar o uso das senhas, como esperado, enquanto a "UsePAM no" reforça a configuração, desativando qualquer outra forma de autenticação com exceção das chaves.

Para que as alterações entrem em vigor, reinicie o servidor SSH:

# /etc/init.d/ssh restart

ou:

# service sshd restart

Transferências SSH

O SSH é um verdadeiro canivete suíço. Além de permitir rodar aplicativos e fazer toda a administração de um servidor remotamente, ele também pode ser usado para transferir arquivos. A forma mais básica de fazer isso é usar o sftp, um pequeno utilitário que faz parte do pacote padrão.

Ele oferece uma interface similar à dos antigos programas de FTP de modo texto, mas todos os arquivos transferidos através dele trafegam através de um túnel encriptado, criado através do SSH. Na prática, temos uma espécie de VPN temporária, criada no

momento em que é efetuada a conexão. A melhor parte é que o próprio SSH cuida de tudo, não é necessário 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 parâmetro "-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 diretório), "ls" (para listar os arquivos) e "pwd" (para ver em qual diretório está). Veja um exemplo:

morimoto@athenas:~$ sftp -o port=2222 morimoto@gdhpress.com.brConnecting to gdhpress.com.br...Password: ********

sftp> lsgdhpress.tar.gz www

sftp> get gdhpress.tar.gzFetching /home/morimoto/gdhpress.tar.gz togdhpress.tar.gz/home/morimoto/gdhpress.tar.gz 100% 523MB 945.1KB/s 09:13

sftp> put backupdb.gzUploading backupdb.gz to /home/morimoto/ backupdb.gzbackupdb.gz 100% 98MB 967KB/s 01:43

sftp> pwdRemote working directory: /home/morimoto

Você pode estar se perguntando como consegui taxas de transferência de quase 1 MB/s tanto para download quanto para upload. O segredo aqui é que não 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 conexão com o segundo a partir dele. Se os dois servidores estão ligados a portas de 10 megabits e existir uma boa conectividade entre eles, taxas de até 1 MB/s são perfeitamente normais. Se você pagar um pouco a mais para ter portas de 100 megabits, então é possível 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 diretório local. Digamos, por exemplo, que você está atualmente no diretório "/mnt/arquivos". Ao abrir a conexão via sftp, tudo que você baixar será colocado automaticamente neste diretório. Mas, digamos que você queira baixar um determinado arquivo para o diretório "/home/joao". Você usaria, então, o comando "lcd /home/joao" para mudar o diretório 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 diretório local e depois o "put arquivo" para dar upload.

Naturalmente, existem meios mais práticos de transferir os arquivos, usando programas gráficos que suportam o sftp. O dois mais usados são o próprio Konqueror (no KDE) e o Nautilus (no Gnome), que além de serem gerenciadores de arquivos, suportam o uso de diversos protocolos de transferência, incluindo o sftp.

No Konqueror, digite "fish://", seguido pelo login e o endereço do servidor (separados por uma arroba) na barra de endereços, como em "fish://gdh@gdhn.com.br". Ele exibe uma janela gráfica pedindo a confirmação da identidade do servidor (apenas na primeira conexão) e em seguida outra, solicitando a senha. Depois de estabelecida a conexão, você tem acesso direto aos arquivos do servidor, dentro das permissões da sua conta de usuário. Você pode também especificar diretamente uma pasta no servidor remoto que quer acessar (por padrão você cai na pasta home), como em "fish://gdh@gdhn.com.br/home/revista/".

Para tornar as coisas mais práticas, eu uso o recurso de dividir a janela em duas, que você encontra no "Janela > Separar visão 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 não é muito bom em prever erros com a conexão, se limitando a exibir um "não é possível 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 opção "Tipo de serviço" e forneça o endereço do servidor e o login que será usado, no campo "Nome do Usuário". O campo com a pasta permite especificar qual pasta será acessada por padrão ao efetuar a conexão, 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 forneça a senha.

A grande limitação do sftp (e das interfaces gráficas para ele) é que ele exige intervenção manual e, por isso, não é adequado para uso em scripts para realizar transferências 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 endereço 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 também as opções "-p" (que preserva as permissões de acesso além das datas de criação e modificação do arquivo original), "-r" (que permite copiar pastas, recursivamente), "-v" (verbose, onde são mostradas todas as mensagens) e "-C" (que ativa a compressão 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 opção "-r", você pode especificar diretamente uma pasta no primeiro parâmetro, o que faz com que todo o seu conteúdo seja transferido. Esta opção é interessante para backups.

O SSH pode ser ainda usado como "meio de transporte" por outros programas, como no caso do rsync, um utilitário que permite sincronizar uma pasta local com uma pasta do servidor. Ele é capaz de fazer uma cópia diferencial, transferindo apenas os trechos dos arquivos que foram modificados o que o torna um utilitário quase que ideal para backup de pastas com um grande volume de arquivos. Ele é capaz inclusive de consertar arquivos danificados e dar upload de atualizações, enviando apenas as partes dos arquivos que forem diferentes, o que torna a transferência muito mais rápida.

O uso básico do rsync, para sincronizar duas pastas locais, seria "rsync -a origem/ destino/". A pasta destino poderia ser um segundo HD, um cartão de memória 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 diretórios 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" vão para a pasta /backup do servidor e no segundo eles são recuperados, subscrevendo os arquivos locais. A parte mais significativa deste comando é o parâmetro "--rsh="ssh -l gdh", que diz para o rsync usar um programa externo (o SSH) para fazer o trabalho.

Uma observação é que usando apenas os parâmetros "-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 confusão. Se você preferir que os arquivos que não existem mais sejam deletados ao atualizar o backup, adicione o parâmetro "--delete", como em:

$ rsync -av --delete --rsh="ssh -l gdh" /home/gdh/ gdh@gdhn.com.br:/backup

O rsync não vem instalado por padrão na maioria das distribuições, 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 condições normais não suportam encriptação é usar o SSH para criar túneis seguros, ligando uma das portas da sua máquina à porta do servidor onde o serviço em questão está ativo. Nesse caso, é criada uma espécie de VPN temporária, através da qual é possível acessar o serviço de forma segura. Todas as informações transmitidas são encriptadas pelo SSH, tornando seguros mesmo protocolos "escancarados", como o Telnet e o FTP. Um dos usos mais comuns para este recurso é encriptar sessões do VNC, evitando que pessoas mal intencionadas tenham acesso ao que foi feito dentro da sessão, mesmo que ela seja interceptada.

O VNC utiliza uma chave de encriptação de mão única durante a autenticação, de forma que a senha não circula abertamente pela rede. Isso impede que alguém sniffando a rede consiga capturar sua senha do VNC, como acontece no caso do Telnet, por exemplo. Apesar disso, o algoritmo de encriptação de senha usado pelo VNC não é muito seguro e, depois que a conexão é iniciada, os dados são enviados de forma não-encriptada, abrindo a possibilidade de que alguém 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 sensíveis, como administrar servidores, acessar sistemas bancários, etc., pode implantar uma camada extra de segurança, utilizando o VNC em conjunto com o SSH. Nesse caso, a segurança é quase total, pois além de ser necessária uma dupla autenticação (primeiro no SSH e depois no VNC), todos os dados são transmitidos através da rede de forma encriptada, utilizando um algoritmo reconhecidamente seguro.

Para utilizar o SSH em conjunto com o VNC, utilizamos a opção "-L", que permite redirecionar uma determinada porta local para uma porta no servidor, criando o túnel. 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 número do display (5901, 5902, 5903, etc.). Note que a porta é diferente do servidor Java, acessível utilizando o browser, que utiliza as portas de 5800 em diante.

Se você vai acessar o display 1 (porta 5901), na máquina 220.132.54.78, precisamos orientar o SSH a redirecionar esta porta para uma porta acessível pelo cliente VNC (a própria porta 5901, ou qualquer outra) no PC local. Para isso, é necessário 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 usuário na máquina remota. O SSH pedirá a senha (ou passphrase) e, pronto, o túnel estará criado.

Tudo o que você precisa fazer agora é abrir o cliente VNC e acessar o endereço "127.0.0.1:1". Isso fará com que o cliente acesse a porta 5901 na máquina local, que por sua vez será redirecionada (através do túnel) para a porta 5901 do servidor remoto. Você usará o VNC da mesma forma, mas desta vez usando um túnel seguro.

Se por acaso a porta 5901 local já estiver em uso, você pode simplesmente criar o túnel apontando para outra porta da sua máquina. Se você fosse acessar o display 4 (porta 5904) no servidor 192.168.0.4, redirecionando-o para a porta 5905 (display 5) da máquina local, logando-se usando o usuário "tux", o comando seria:

$ ssh -f -N -L5905:192.168.0.4:5904 -l tux 192.168.0.4

Nesse caso, você acessaria o endereço "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 atualização 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 segurança, a troca acaba sendo vantajosa.

Além do VNC, este comando pode ser usado para criar túneis 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 usuário.

O parâmetro "-f" dentro do comando faz com que ele seja executado em background, liberando o terminal depois que a conexão é 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 opção principal, que especifica que queremos fazer um redirecionamento de portas. Ele é seguido (sem espaços) pela porta local que receberá a porta remota, o endereço 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 máquina local). Concluindo, o "-l" em seguida especifica o login que será usado para estabelecer a conexão, seguido pelo endereço IP do servidor.

Em resumo, a sintaxe deste longo comando é "ssh -f -N -Lporta-local:servidor:porta-do-servidor -l login servidor" (veja que é necessário especificar o endereço do servidor remoto duas vezes).

Seja qual for a porta destino, todo o tráfego é transportado através da porta do SSH e encaminhada localmente para a porta final. Graças a essa peculiaridade, os túneis são 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 túneis. Em casos em que o servidor remoto esteja configurado para usar uma porta diferente da padrão para o SSH, adicione a opção "-p porta" no início 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 túnel para encriptar todo o tráfego web, de forma que você possa navegar de forma segura, ler seus e-mails, etc. mesmo ao acessar através de uma conexão wireless sem qualquer tipo de encriptação.

Para isso, é preciso que o gateway da rede (ou alguma máquina na Internet, que seja acessível 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 então o SSH para criar um túnel, 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 próximo passo é configurar o navegador na sua máquina 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 túnel criado através 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 conexões de qualquer cliente, já que mesmo passando pelo túnel, o acesso será computado pelo Squid como partindo do seu IP de Internet atual. Um exemplo de configuração do Squid para que o servidor permitisse a conexão de qualquer cliente remoto seria:

http_port 3128visible_hostname gdhacl all src 0.0.0.0/0.0.0.0acl manager proto cache_objectacl localhost src 127.0.0.1acl SSL_ports port 443 563acl Safe_ports port 21 80 443 563 70 210 280 488 59 777 901 1025-65535acl purge method PURGEacl CONNECT method CONNECThttp_access allow manager localhosthttp_access deny managerhttp_access allow purge localhosthttp_access deny purgehttp_access deny !Safe_portshttp_access deny CONNECT !SSL_portshttp_access allow all

Como você pode ver essa configuração simplesmente permite acessos provenientes de qualquer endereço. O truque é que como o servidor será acessado através dos túneis

criados usando o SSH, você pode manter a porta 3128 fechada no firewall do servidor, permitindo apenas conexões através da porta 22. Com isso, o servidor não ficará vulnerável, já que a única forma de chegar até o proxy é criando um túnel até ele através do SSH.

Também tem a possibilidade de criação no Windows mais não sei como configurar.