Entendendo o SSH

O SSH é a minha ferramenta preferida. Ele 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:

ou:

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:

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

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:

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: