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 Este endereço de e-mail está protegido contra spambots. Você deve habilitar o JavaScript para visualizá-lo. :/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 Este endereço de e-mail está protegido contra spambots. Você deve habilitar o JavaScript para visualizá-lo.

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.

Como fazer isso no cliente Windows?
Para fazer isso à partir de um cliente Windows, você vai utilizar o PuTTy e algumas outras ferramentas disponibilizadas pelos mesmos desenvolvedores.

Acesse o site de download do PuTTy (http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html) e faça o download dos arquivos “putty.exe”, “puttygen.exe” e “pageant.exe”. Primeiro,  vamos executar o “puttygen.exe” para gerarmos os certificados do cliente Windows. A tela inicial do PuTTyGen é assim:

Você só vai precisar modificar a opção “Number of bits in a generated key:”, informando o valor “2048″ (sem as aspas duplas). Também, tenha certeza de que a opção “SSH-2 RSA” esteja selecionada e clique em “Generate”. Depois, fique movendo o mouse no espaço logo abaixo da barra de progresso até que o processo esteja finalizado (isso é feito para gerar dados aleatórios para criar o certificado). Após gerar os certificados, o PuttyGen vai ficar assim:

A chave pública será exibida na tela na caixa de texto mais acima da janela do programa, copie tudo o que está nesta caixa e cole em um arquivo texto. Depois envie esse arquivo texto para o servidor  (ou utilize o próprio PuTTy e copie e cole) e adicione o conteúdo dele ao arquivo “authorized_keys”, como explicado anteriormente. Agora, clique no botão “Save public key” e informe o nome do arquivo e o diretório onde o arquivo será salvo. O arquivo da chave pública não precisa ter uma extensão.

Para enviar o arquivo para o servidor seguramente, você pode utilizar o WinSCP (http://winscp.net/eng/download.php) ou o PSCP (desenvolvido pelo mesmo time que desenvolveu o PuTTy). Utilizando o PSCP:

C:\>pscp.exe caminho\para\arquivo-do\certificado\windows Este endereço de e-mail está protegido contra spambots. Você deve habilitar o JavaScript para visualizá-lo. :/root

Isso irá copiar a chave que você gerou através do PuTTyGen para o servidor 192.168.1.104 no diretório /root. No servidor, você deve executar os mesmo passos descritos anteriormente para a chave do cliente Linux. Tenha certeza de utilizar “>>” para não sobrescrever o arquivo de chaves do servidor, apagando todos as outras chaves que eram aceitas.

O certificado privado nunca é exibido pelo PuTTyGen em lugar nenhum de sua janela: você deve salvá-lo direto em um arquivo com extensão “.ppk” (a extensão é obrigatória para a chave privada); e também não deve em hipótese alguma ser copiado para outras máquinas. Porém, antes de salvar a chave privada, você deve definir uma senha para ela. Esta senha é requisitada sempre que você utilizar este certificado para se conectar ao servidor (ela pode e deve ser diferente da senha especificada no servidor). Ou seja, neste ponto ao invés de ter que digitar a senha do servidor você teria que digitar a senha do seu certificado! Trocamos 6 por meia-dúzia já que a senha do seu certificado também deve ser complexa, por motivos óbvios.

Para resolver esse “problema”, vamos utilizar o Pageant. Ele é um programa que irá salvar a senha do seu certificado, assim você não vai precisar digitar senha alguma enquanto se autentica no servidor. Inicie o Pageant com um clique-duplo no arquivo que baixamos do site do PuTTy e depois no ícone dele que fica próximo ao relógio do sistema. Abaixo está a tela incial:

Para ele guardar a senha, devemos indicar qual o arquivo que contém a chave privada. Para isso, clique em “Add Key” e selecione a chave privada. Quando você abrir o arquivo, será exibido um diálogo. Nele você deve inserir a passphrase informada para o PuTTyGen quando o certificado foi gerado. Pronto, agora basta que você primeiro inicie o Pageant antes de utilizar o PuTTy para conseguir logar em um servidor utilizando certificados RSA sem a necessidade de digitar qualquer senha.

Para fazer com que o PuTTy utilize o certificado que você criou (e adicionou ao banco de dados do servidor), primeiro crie um perfil para que possamos salvar todas as modificações que faremos (para que não precisemos fazer isso todas as vezes). Para criar o perfil, primeiro digite o IP ou nome DNS do servidor ao qual você vai se conectar na caixa de texto “Host name (or IP address)” da tela inicial do PuTTy. Depois, digite um nome qualquer (pode ser o nome DNS, o IP ou um nome como “Servidor de e-mails”) em “Saved sessions”. Clique em “Save” e o perfil será criado e exibido na lista de servidores salvos do PuTTy. Para ter certeza de que está alterando o perfil correto, selecione o perfil que você acabou de salvar e clique em “Load”.

Agora, você terá que acessar as opções oferecidas no menu à esquerda da janela do PuTTy. Neste menu, você irá encontrar uma opção chamada “Connection” e, logo abaixo dela, uma opção chamada “Data”, clique nela. Em “Auto-login username” digite o nome do usuário que você quer utilizar para se conectar ao servidor. No meu exemplo, digitei “root” mesmo.

Agora, vamos dizer ao PuTTy onde está localizada a chave privada para que ele possa utilizá-la durante a conexão. Para isso, no menu à esquerda, vá em “Connection”, expanda “SSH” e clique em “Auth”. Clique no botão “Browse” e selecione o arquivo com a chave privada.

Agora, volte para “Session” (a primeira opção, no topo do menu à esquerda) e clique no botão “Save”. Pronto, se tudo correu bem, basta você dar dois cliques no nome do perfil que você salvou e você irá conseguir logar automaticamente no servidor Linux.

É, a configuração é bem mais simples no Linux!

Toque final no servidor

Agora, você não vai mais precisar que o SSH permita que os usuários tentem autenticar-se através de senhas. Por isso, você pode desabilitar esta opção editando o arqivo /etc/ssh/sshd_config. Procure a linha:

PasswordAuthentication yes

E troque o “yes” por “no”:

PasswordAuthentication no

Se houver um “#” no início dessa linha, remova-o para que a opção surta efeito. Agora salve o arquivo e reinicie o daemon do SSH. No CentOS

# service sshd restart

No Debian:

# /etc/init.d/ssh restart

ATENÇÃO: só faça isso depois de testar e garantir que a autenticação através de certificados está funcionando corretamente! Se houver algum problema, você pode ficar sem acesso ao servidor.

Conclusão

Esta configuração além de ser prática, aumenta em muito a segurança do seu servidor eliminando o ponto fraco da maioria dos sistemas: senhas fracas. Uma boa idéia é gerar um certificado para cada usuário (recomendo que gere certificados de 2048 bits), assim você elimina completamente as chances de usuários utilizarem senhas fracas.

Você utiliza alguma técnica diferente? O que você faz? Deixe a sua dica nos comentários! Aproveite também e me mande suas sugestões e críticas!

Se você gostou deste post, também vai gostar do post “SSH Port Forwarding” onde eu mostro como você pode acessar um recurso de uma rede remota fazendo uma VPN com SSH bem rápido.

Fonte: http://www.pedropereira.net/ssh-sem-senha-autenticacao-atraves-de-certificados-rsa/