Autenticação SSH por Chaves Públicas

Nota: Este é o terceiro tutorial da série sobre SSH. Se você perdeu o anterior sobre as primeiras conexões, pode encontrá-lo aqui: Primeiras Conexões SSH.

No tutorial anterior, aprendemos a fazer nossas primeiras conexões SSH usando senhas. Embora funcional, a autenticação por senha tem suas fraquezas: senhas podem ser adivinhadas por ataques de força bruta, podem ser fracas, ou podem ser interceptadas se houver alguma falha (extremamente improvável com SSH, mas possível em outros contextos). É hora de dar um passo adiante e adotar o método de autenticação preferido, mais seguro e mais conveniente: as chaves públicas SSH.

Este método elimina a necessidade de digitar senhas repetidamente e oferece um nível de segurança muito superior.

O Conceito Mágico: Criptografia Assimétrica

A autenticação por chave pública baseia-se em um princípio fundamental da criptografia moderna: a criptografia assimétrica, também conhecida como criptografia de chave pública/privada.

Funciona assim:

1. Geração do Par: Você gera um par de chaves digitais matematicamente relacionadas:
   • Uma Chave Privada: Esta chave é secreta e nunca deve ser compartilhada. Ela permanece segura na sua máquina local. Pense nela como sua identidade digital secreta.
   • Uma Chave Pública: Esta chave pode ser compartilhada livremente. Você a distribuirá para os servidores aos quais deseja acessar. Pense nela como uma “fechadura” digital que só a sua chave privada pode “abrir”.
2. O Desafio: Quando você tenta se conectar a um servidor onde sua chave pública está registrada:
   • O servidor usa sua chave pública para criptografar uma mensagem aleatória (um desafio) e a envia para o seu cliente SSH.
   • Somente a sua chave privada correspondente pode descriptografar essa mensagem corretamente.
   • Seu cliente SSH usa sua chave privada para descriptografar o desafio e prova ao servidor que possui a chave privada, sem nunca transmiti-la pela rede.
3. Autenticação: Se o cliente conseguir descriptografar o desafio, o servidor sabe que você é quem diz ser (pois só o dono da chave privada correspondente poderia fazê-lo) e concede o acesso.

A Beleza Disso: Sua senha (a chave privada) nunca trafega pela rede! O processo prova sua identidade sem expor seu segredo.

Gerando Seu Par de Chaves Seguras (ssh-keygen)

O utilitário padrão para gerar pares de chaves SSH é o ssh-keygen, que já vem com o OpenSSH.

Abra seu terminal local e execute:

ssh-keygen -t ed25519

• -t ed25519: Especifica o tipo (algoritmo) da chave a ser gerada. Ed25519 é o algoritmo atualmente recomendado por ser moderno, rápido e seguro.
• Alternativa: Se precisar de compatibilidade com sistemas mais antigos que não suportam Ed25519, você pode usar RSA com um tamanho de chave robusto: ssh-keygen -t rsa -b 4096 (onde -b 4096 define o tamanho em bits; 4096 é considerado seguro atualmente).

O comando fará algumas perguntas:

1. Enter file in which to save the key (/home/seu_usuario/.ssh/id_ed25519):
   • Ele sugere salvar a chave privada no arquivo id_ed25519 dentro do diretório oculto .ssh na sua pasta pessoal. Este é o local padrão e recomendado. Apenas pressione Enter para aceitar.
   • A chave pública correspondente será salva automaticamente no mesmo local com a extensão .pub (ex: id_ed25519.pub).
2. Enter passphrase (empty for no passphrase):
   • MUITO IMPORTANTE! Esta é a sua chance de proteger sua chave privada com uma senha (passphrase). Se alguém conseguir acesso físico ou remoto à sua máquina e roubar seu arquivo de chave privada, essa passphrase será a última linha de defesa, impedindo que usem sua chave imediatamente.
   • Recomendação: SEMPRE defina uma passphrase forte. Pense nela como a senha mestra para sua identidade SSH. Deixe em branco apenas em cenários muito específicos de automação onde a interação humana é impossível (e mesmo assim, existem alternativas mais seguras).
   • Digite uma passphrase segura e pressione Enter.
3. Enter same passphrase again:
   • Confirme a passphrase digitando-a novamente e pressionando Enter.

Se tudo correu bem, você verá uma mensagem indicando que as chaves foram salvas e uma “arte” representando a impressão digital da sua chave:

Your identification has been saved in /home/seu_usuario/.ssh/id_ed25519
Your public key has been saved in /home/seu_usuario/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:SomeRandomLookingFingerprint seu_usuario@sua_maquina
The key's randomart image is:
+--[ED25519 256]--+
|        .        |
|       + .       |
|      . B .      |
|     . * + .     |
|    . = S = .    |
|   . * = * +     |
|    o B O.* .    |
|   . =.E=o..     |
|    ..o+o...     |
+----[SHA256]-----+

Agora você tem seu par de chaves! A id_ed25519 é a privada (secreta) e a id_ed25519.pub é a pública (compartilhável).

Gerenciando a Passphrase com ssh-agent:

Digitar a passphrase toda vez que usar a chave pode ser inconveniente. É aqui que o ssh-agent (que veremos em detalhes em um tutorial futuro) entra. Ele é um programa auxiliar que mantém sua chave privada descriptografada na memória por um tempo, permitindo que você a use várias vezes após digitar a passphrase apenas uma vez por sessão.

Transferindo Sua Chave Pública para o Servidor

Para que o servidor possa autenticá-lo usando sua chave, ele precisa conhecer sua chave pública. Você precisa copiar o conteúdo do seu arquivo .pub para um arquivo específico no servidor.

Método Recomendado: ssh-copy-id

O OpenSSH fornece um script utilitário chamado ssh-copy-id que automatiza esse processo de forma segura e correta (incluindo a configuração das permissões adequadas no servidor).

A sintaxe é simples:

ssh-copy-id <usuario>@<hostname_ou_ip_do_servidor>

• Ele se conectará ao servidor usando a autenticação por senha (você precisará digitá-la desta vez).
• Ele copiará o conteúdo da sua chave pública padrão (~/.ssh/id_ed25519.pub, ~/.ssh/id_rsa.pub, etc.) e o adicionará ao arquivo ~/.ssh/authorized_keys no diretório home do usuário remoto.
• Ele também garantirá que o diretório ~/.ssh e o arquivo authorized_keys no servidor tenham as permissões corretas.

Exemplo Prático:

Para copiar nossa chave id_ed25519.pub para o Servidor KVM (192.168.0.254) para o usuário user_kvm:

ssh-copy-id user_kvm@192.168.0.254

Você será solicitado a digitar a senha de user_kvm no servidor. Após a conclusão, ele exibirá uma mensagem sugerindo que você tente fazer login com ssh user_kvm@192.168.0.254 para verificar se funcionou (e para ver se ele pede a passphrase da sua chave, se você definiu uma).

Dica: Se você gerou sua chave com um nome não padrão, pode especificar qual chave pública copiar usando a flag -i: ssh-copy-id -i ~/.ssh/chave_especial.pub user_kvm@192.168.0.254.

Método Manual (Alternativa)

Se ssh-copy-id não estiver disponível ou se você preferir fazer manualmente, o processo é:

1. Copie o conteúdo da sua chave pública local:

   cat ~/.ssh/id_ed25519.pub
   

   Selecione e copie toda a saída (geralmente uma linha longa começando com ssh-ed25519 ou ssh-rsa).

2. Conecte-se ao servidor remoto usando senha:

   ssh user_kvm@192.168.0.254
   

3. No servidor remoto, edite (ou crie) o arquivo ~/.ssh/authorized_keys:
   • Crie o diretório .ssh se ele não existir: mkdir -p ~/.ssh
   • Abra o arquivo authorized_keys com um editor de texto (como nano ou vim): nano ~/.ssh/authorized_keys
   • Cole o conteúdo da sua chave pública (copiado na etapa 1) em uma nova linha no arquivo.
   • Salve e feche o editor (em nano, Ctrl+O para salvar, Enter para confirmar, Ctrl+X para sair).
4. Ajuste as permissões no servidor (CRUCIAL!):

   chmod 700 ~/.ssh
   chmod 600 ~/.ssh/authorized_keys
   exit # Desconecte do servidor
   

   Se as permissões estiverem muito abertas, o SSH se recusará a usar o arquivo authorized_keys por segurança.

O método ssh-copy-id é claramente mais simples e menos propenso a erros.

A Importância das Permissões Corretas

O SSH é muito rigoroso quanto às permissões de arquivos e diretórios relacionados às chaves, tanto no cliente quanto no servidor. Permissões incorretas podem fazer com que a autenticação por chave falhe silenciosamente (o servidor simplesmente volta a pedir senha) ou explicitamente.

Regras Essenciais:

• No Cliente:
  • Diretório ~/.ssh: Deve ter permissão 700 (drwx——). Apenas o proprietário pode ler, escrever e executar (entrar no diretório).

      chmod 700 ~/.ssh
    

  • Chave Privada (~/.ssh/id_ed25519, etc.): Deve ter permissão 600 (-rw——-). Apenas o proprietário pode ler e escrever.

      chmod 600 ~/.ssh/id_ed25519
    

• No Servidor:
  • Diretório ~/.ssh: Deve ter permissão 700 (drwx——).

      # No servidor:
      chmod 700 ~/.ssh
    

  • Arquivo authorized_keys: Deve ter permissão 600 (-rw——-).

      # No servidor:
      chmod 600 ~/.ssh/authorized_keys
    

O comando ssh-copy-id geralmente cuida das permissões no servidor, mas é sempre bom saber como verificá-las e corrigi-las (ls -ld ~/.ssh e ls -l ~/.ssh/authorized_keys).

Conectando com Sua Chave

Após copiar sua chave pública para o servidor e garantir que as permissões estão corretas, tente conectar novamente:

ssh user_kvm@192.168.0.254

O que deve acontecer:

1. O cliente SSH tentará usar sua chave privada padrão (~/.ssh/id_ed25519 ou ~/.ssh/id_rsa).
2. Se você definiu uma passphrase para a chave, o cliente SSH solicitará que você a digite:

   Enter passphrase for key 
   '/home/seu_usuario/.ssh/id_ed25519
   ':
   

   Digite a passphrase da chave (não a senha do usuário no servidor) e pressione Enter.

3. Se a chave for válida (e a passphrase correta, se houver), o servidor o autenticará e você estará conectado sem precisar digitar a senha do usuário do servidor!

Se você usou um nome não padrão para sua chave, lembre-se de usar a flag -i:

ssh -i ~/.ssh/chave_especial user_kvm@192.168.0.254

Passo Final: Desabilitar Autenticação por Senha no Servidor

Agora que a autenticação por chave está funcionando, o último passo para maximizar a segurança é desabilitar completamente a autenticação por senha no servidor SSH. Isso elimina o risco de ataques de força bruta contra senhas.

CUIDADO: Faça isso somente depois de ter certeza absoluta de que sua autenticação por chave pública está funcionando corretamente para todos os usuários que precisam de acesso. Caso contrário, você pode ficar trancado fora do servidor!

1. Conecte-se ao servidor (usando sua chave recém-configurada).
2. Edite o arquivo de configuração do servidor SSH com privilégios de root:

   sudo nano /etc/ssh/sshd_config
   

3. Encontre a linha PasswordAuthentication. Ela pode estar comentada (#) ou definida como yes.
4. Altere ou descomente a linha para:

   PasswordAuthentication no
   

5. Encontre a linha ChallengeResponseAuthentication (usada para outros métodos interativos, às vezes incluindo senhas via PAM) e defina-a como no também, por segurança:

   ChallengeResponseAuthentication no
   

6. Garanta que a autenticação por chave pública está habilitada (geralmente é o padrão, mas verifique):

   PubkeyAuthentication yes
   

7. Salve e feche o arquivo (Ctrl+O, Enter, Ctrl+X em nano).
8. Reinicie o serviço SSHd para aplicar as alterações:

   sudo systemctl restart sshd
   # ou em sistemas mais antigos:
   # sudo service ssh restart
   # ou
   # sudo /etc/init.d/ssh restart
   

Agora, o servidor SSH aceitará apenas conexões autenticadas por chave pública (ou outros métodos que você possa ter habilitado, como Kerberos), tornando-o muito mais resistente a ataques.

Conclusão

Parabéns! Você dominou o método mais seguro e recomendado para autenticação SSH: chaves públicas. Aprendemos o conceito por trás da criptografia assimétrica, como gerar pares de chaves com ssh-keygen, a importância crucial da passphrase, como transferir a chave pública para o servidor usando ssh-copy-id (e manualmente), a necessidade de permissões corretas e, finalmente, como desabilitar a autenticação por senha no servidor para segurança máxima.

Com a autenticação por chave configurada, seus acessos remotos são mais seguros e, com a ajuda do ssh-agent (que exploraremos mais tarde), também podem ser mais convenientes.

No próximo tutorial, vamos mergulhar na configuração avançada do servidor SSH, explorando as opções disponíveis no arquivo sshd_config para ajustar ainda mais a segurança e o comportamento do seu servidor.