O OpenSSH é talvez a ferramenta mais utilizada por administradores de sistemas atualmente. Quando de seu desenvolvimento, o objetivo dele foi substituir ferramentas inseguras como telnet, rlogin, etc. Ele permite que você se conecte de forma segura a qualquer dispositivo (como switches, roteadores, servidores Linux, FreeBSD, OpenBSD, Solaris, etc.) que esteja executando um servidor SSH com suporte aos protocolos 1 ou 2.

Aqui vamos ver como configurar o SSH para se autenticar utilizando certificados, para deixar o acesso ao seu servidor mais prático e mais simples. Todos os passos descritos aqui não dependem de distribuição X ou Y: você pode executar este procedimento em qualquer distribuição e tudo irá funcionar tranquilamente.

O problema

Sempre antes de você se conectar a um servidor via SSH, uma tentativa de estabelecer a identidade desta máquina é feita. Quando não é possível estabelecer a identidade, um aviso como o seguinte é exibido:

The authenticity of host ’192.168.1.104 (192.168.1.104)’ can’t be established.
RSA key fingerprint is 8c:d0:d2:2a:14:d6:28:44:84:be:8d:21:f7:9e:d1:7b.
Are you sure you want to continue connecting (yes/no)?

Basicamente, o que essa mensagem quer te dizer é que não foi possível garantir que o host com IP 192.168.1.104 é realmente o host 192.168.1.104 ao qual você queria se conectar (alguém pode ter derrubado a máquina 192.168.1.104 e substituido por outra, com um software que grava todos os usuários e senhas digitados enquanto simula um diálogo do SSH). Também é fornecida para você a chave RSA do host, para que você confira (alguém faz isso? :) ). E, finalmente, pergunta se você quer continuar mesmo assim. Respondendo “yes”, o processo de autenticação continua sem problemas (mas você ainda não pode garantir que é o host certo até que tenha fornecido usuário e senha); respondendo “no”, você volta para o BASH, sem acesso ao servidor!

Para resolver este problema, você pode utilizar certificados que garantem a autenticidade tanto do cliente quanto do servidor. Além disso, como é praticamente impossível alguém conseguir o seu certificado sem acesso à sua máquina, você nem vai precisar utilizar senhas para se conectar (o que é excelente quando se usa muito o SCP para copiar arquivos entre hosts).

Também existe o problema do brute-force. Neste tipo de ataque, serão testadas várias combinações de usuários/senhas. É uma forma garantida de que, em um determinado momento, o atacante irá conseguir encontrar uma combinação de usuário/senha válidos. Veja bem, em momento algum eu disse que é rápido e/ou viável, disse que é possível e muito comum na Internet.

Para melhorar a segurança dele neste ponto, você tem pelo menos duas alternativas:

• Softwares de monitoramento de logs: Existem vários softwares desse tipo (por exemplo sshguard, fail2ban, blockhosts, etc). Eles funcionam monitorando os logs gerados pelo SSH. Quando encontram muitas falhas de login seguidas vindas de um mesmo IP, tomam uma medida para proteger o servidor como, por exemplo, bloquear o host de origem através do IPTables automaticamente.
• Autenticação através de certificados: Aqui, o SSH irá autenticar-se utilizando certificados ao invés de senhas. Assim, quem não tiver um certificado válido não conseguirá se conectar ao servidor, não importa quantos nomes de usuários e senhas tente utilizar e as senhas não são enviadas através da rede.

Embora softwares de monitoramento de logs sejam bastante efetivos, eles muito provavelmente não funcionam em dispositivos como switches, roteadores, etc., além disso é mais fácil que eles possuam algum bug do que a autenticação através de certificados que já foi extensivamente testada e provada por milhares de pessoas. Por isso, recomendo que você utilize a segunda opção em todos os seus dispositivos que possuam SSH habilitado.

O melhor de tudo isso, é que implantar esse tipo de autenticação é extremamente simples. Vamos lá!

A configuração

A autenticação vai acontecer assim:

• O cliente SSH vai enviar uma requisição para o servidor pedindo uma conexão
• O servidor SSH vai pedir o certificado do cliente para garantir que o cliente realmente tem a permissão de se conectar
• Quando receber o certificado, o servidor vai verificar em seu banco de dados se o certificado está correto. Caso esteja, a sessão será aberta.

Para isso, vamos começar gerando o certificado do cliente. Para isso execute o seguinte comando:

# ssh-keygen -t rsa -b 2048

O “ssh-keygen” não precisa necessariamente ser executado como root. Se a chave criada para o usuário “x” for reconhecida pelo servidor, o usuário “x” poderá logar como “root” no servidor, explico isso mais com mais detalhes adiante.

Executando o “ssh-keygen” será gerada uma chave RSA de 2048 bits (eu especifiquei na linha comando, mas não é necessário já que este é o padrão). O mínimo para o RSA é de 768 bits. Algumas perguntas serão feitas para você. Os valores exibidos entre “()” são os valores padrão e, se quiser mantê-los, basta pressionar “enter”, não precisa escrever a opção novamente:

• Enter file in which to save the key (/root/.ssh/id_rsa): Aqui você apenas define o diretório onde os certificados gerados serão armazenados;
• Enter passphrase (empty for no passphrase): Você tem a opção de digitar uma senha para o certificado. Isso não é necessário, você pode simplesmente apertar “enter” aqui e na próxima pergunta, que apenas confirma a passphrase digitada anteriormente.

Agora, temos que falar para o servidor que ele deverá aceitar esse certificado. Para isso, transferimos o certificado para o servidor de forma segura:

# scp /root/.ssh/id_rsa.pub root@192.168.1.104:/root

Isso irá copiar a chave pública do cliente para o servidor, no diretório /root. Agora, temos que adicionar esse certificado ao banco de dados que contém os certificados aceitos por esse servidor. No servidor, execute:

# cat id_rsa.pub >> /root/.ssh/authorized_keys

Vale lembrar que o diretório “.ssh” só existirá se você tiver utilizado o SSH pelo menos 1 vez, anteriormente (se ele não existir, pode criá-lo na mão). Caso o arquivo authorized_keys não exista, basta executar o comando citado acima.

Pronto! Agora você já pode se conectar ao servidor de uma forma absolutamente segura, sem medo que roubem a sua senha (já que você não a envia através da rede) e sem medo de ataques brute force (que são totalmente inofensivos contra autenticação baseada em certificados RSA).

Com qual usuário eu vou logar?

A autenticação via certificados pode ser utilizada para qualquer usuário válido no servidor, não apenas para o usuário root. Seguindo os passos descritos anteriormente, você poderá logar sem senha como root utilizando o seguinte comando:

$ ssh root@192.168.1.104

Isso, considerando que você não esteja executando este comando como root. Se estiver, basta:

# ssh 192.168.1.104

Isso acontece pois, quando você não especifica um usuário, o SSH entende que o login a ser utilizado para logar no servidor remoto é o mesmo do usuário que executou o comando. Portanto, se você executou o comando acima como root, você não precisa da parte “root@” do comando. Isso acontece com qualquer usuário, mas dois detalhes devem ser observados:

• O usuário deve existir no servidor e seu login deve ser permitido através do SSH;
• A sua chave pública deve ser adicionada ao arquivo “authorized_keys” do usuário que deseja utilizar, não o do root. Portanto, o comando para adicionar a chave seria:
  # cat id_rsa.pub >> /home/nome-do-usuário/.ssh/authorized_keys

Além disso, é necessário que o usuário especificado tenha acesso de leitura e escrita ao “authorized_keys”.

Resumindo, se a sua chave pública está presente no arquivo “authorized_keys” do usuário “x” mas não do usuário “y”, você poderá fazer o login como usuário “x” mas não como “y”. Esta regra é a mesma para todos os usuários do sistema.