A Internet permite realizar um grande número de operações à distância, nomeadamente a administração de servidores ou a transferência de ficheiros. O protocolo e os r-comandos BSD (rsh, rlogin et rexec), que permitem efectuar estas tarefas distantes, possuem o inconveniente essencial de deixar circular às claras na rede as informações trocadas, nomeadamente o identificador (login) e a senha para o acesso à máquina distante. Assim, um pirata situado numa rede entre o utilizador e a máquina distante tem a possibilidade de ouvir o tráfego, ou seja, de utilizar instrumento chamado sniffer, capaz de capturar as tramas que circulam na rede e assim obter o identificador e a senha de acesso à máquina distante.

Ainda que as informações trocadas não possuam um grande nível de segurança, o pirata obtém um acesso a uma conta na máquina distante e pode eventualmente estender os seus privilégios sobre a máquina para obter um acesso administrador (root).

Já que é impossível dominar o conjunto das infra-estruturas físicas situadas entre o utilizador e a máquina distante (a Internet é, por definição, uma rede aberta), a única solução é recorrer a uma segurança ao nível lógico (a nível dos dados).

O protocolo SSH (Secure Shell) responde a esta problemática permitindo a utilizadores (ou serviços TCP/IP) aceder a uma máquina através de uma comunicação codificada (chamado túnel).

O protocolo SSH

O protocolo SSH (Secure Shell) foi criado em 1995 pelo Finlandês Tatu Ylönen.

Trata-se de um protocolo que permite a um cliente (um utilizador ou mesmo uma máquina) abrir uma sessão interactiva numa máquina distante (servidor) para enviar comandos ou ficheiros de maneira protegida:

• Os dados que circulam entre o cliente e o servidor são codificados, o que garante a sua confidencialidade (ninguém além do servidor ou do cliente pode ler as informações que transitam na rede). Não é por conseguinte possível ouvir a rede com a ajuda de um analisador de tramas.
• O cliente e o servidor autenticam-se mutuamente para ter a certeza de que as duas máquinas que comunicam são efectivamente as que cada uma das partes crê ser. Assim, já não é possível que um pirata usurpe a identidade do cliente ou do servidor (spoofing).

A versão 1 do protocolo (HS) proposta a partir de 1995 tinha por objectivo servir de alternativa às sessões interactivas (shells) como Telnet, rsh, rlogin e rexec. Este protocolo possuía, contudo, uma falha que permite a um pirata inserir dados no fluxo codificado. É a razão pela qual, em 1997, a versão 2 do protocolo (SSH2) foi proposta como documento de trabalho (draft) ao IETF. Os documentos que definem o protocolo são acessíveis em linha em http://www.ietf.org/html.charters/secsh-charter.html.

O Secure Shell Versão 2 propõe igualmente uma solução de transferência de ficheiros protegida (SFTP, Secure File Transfer Protocol).

O SSH é um protocolo, quer dizer, um método standard que permite às máquinas estabelecer uma comunicação protegida. A esse respeito, existem numerosas aplicações de clientes e de servidores HS. Alguns são pagas, outras são gratuitas ou open source: encontrará diversos clientes HS na secção de telecarregamentos de Kioskea.

Funcionamento de SSH

O estabelecimento de uma conexão HS faz-se em várias etapas:

• Inicialmente, o servidor e o cliente identificam-se mutuamente para instalar um canal protegido(nível de transporte protegido).
• Subsequentemente, o cliente autentica-se junto do servidor para obter uma sessão.

Instalação do canal protegido

A instalação de um nível de transporte protegido começa por uma fase de negociação entre o cliente e o servidor para acordarem sobre os métodos de codificação a utilizar. Com efeito, o protocolo SSH é suposto funcionar com um grande número de algoritmos de codificação, é por isso que o cliente e o servidor devem inicialmente trocar os algoritmos que suportam.

Seguidamente, para estabelecer uma ligação protegida, o servidor envia a sua chave pública de hóspede (host key) ao cliente. O cliente gera uma chave de sessão de 256 bits que codifica graças à chave pública do servidor, e envia ao servidor a chave de sessão codificada, bem como o algoritmo utilizado. O servidor decifra a chave de sessão graças à sua chave privada e envia uma mensagem de confirmação codificada com a ajuda da chave de sessão. A partir daí, o resto das comunicações é codificado graças a um algoritmo de codificação simétrico utilizando a chave de sessão compartilhada pelo cliente e o servidor.

Toda a segurança da transacção assenta na garantia que têm o cliente e o servidor sobre a validade das chaves de hóspede da outra parte. Assim, aquando da primeira conexão a um servidor, o cliente afixa geralmente uma mensagem que pede para aceitar a conexão (e apresenta eventualmente um condensado da chave de hóspede do servidor):

Host key not found from the list of known hosts. 
Are you sure you want to continue connecting (yes/no)?

Pelo contrário, de acordo com a sua configuração, o servidor pode às vezes verificar que o cliente é efectivamente aquele que ele diz ser. Assim, se o servidor possuir uma lista de hóspedes autorizados a conectar-se, vai codificar uma mensagem com a ajuda da chave pública do cliente (que possui na sua base de dados de chaves de hóspedes), para verificar se o cliente está em condições de decifrá-la com a ajuda da sua chave privada (fala-se então de challenge).

A autenticação

Uma vez que a conexão protegida estiver instalada entre o cliente e o servidor, o cliente deve identificar-se no servidor para obter um direito de acesso. Existem vários métodos:

• o método mais conhecido é a tradicional palavra-passe. O cliente envia um nome de utilizador e uma palavra-passe ao servidor através da comunicação protegida e o servidor verifica se o utilizador interessado tem acesso à máquina e se a palavra-passe fornecida é válida
• um método menos conhecido mas mais flexível é a utilização de chaves públicas. Se a autenticação por chave for escolhida pelo cliente, o servidor vai criar um challenge e dar um acesso ao cliente se este último conseguir decifrar o challenge com a sua chave privada