Como configurar acesso SSH seguro via Chaves RSA (sem senha)

9 min de leitura Segurança
Como configurar acesso SSH seguro via Chaves RSA (sem senha)

Introdução

Se você gerencia um servidor VPS ou uma instância Cloud na Toda Solução, sabe que a segurança é o pilar fundamental da sua infraestrutura. Um dos vetores de ataque mais comuns e perigosos contra servidores Linux é o ataque de força bruta (brute force), onde bots automatizados tentam incessantemente adivinhar senhas de usuários como root ou admin através da porta 22.

Para mitigar esse risco, a prática recomendada pela comunidade de segurança e por administradores de sistemas é a implementação de autenticação baseada em chaves SSH (SSH Key Authentication). Diferente das senhas tradicionais, que podem ser vulneráveis a ataques de dicionário, as chaves RSA utilizam um par de arquivos criptográficos: uma chave pública, que fica armazenada no servidor, e uma chave privada, que deve permanecer exclusivamente na sua máquina local.

Neste tutorial, você aprenderá o processo completo para:

  • Gerar um par de chaves RSA seguro no seu computador local.
  • Transferir a chave pública para o seu servidor remoto.
  • Configurar o serviço SSH para desabilitar completamente o login por senha.

Ao final deste guia, seu acesso será muito mais rápido e, acima de tudo, blindado contra tentativas de invasão por senha.

Pré-requisitos

Antes de iniciar a configuração do acesso SSH via chaves RSA, certifique-se de que você atende aos requisitos abaixo para evitar o bloqueio de acesso ao seu servidor. Este procedimento é crítico e, se feito incorretamente, pode impedir que você gerencie sua infraestrutura remotamente.

  • Acesso ao Servidor: Você deve possuir acesso atual via SSH utilizando uma senha ou através do console web fornecido pelo painel da Toda Solução.
  • Privilégios de Root: É necessário ter permissões de superusuário (sudo ou root) para alterar os arquivos de configuração do serviço SSH.
  • Cliente SSH instalado: Sua máquina local (onde as chaves serão geradas) deve possuir um cliente SSH funcional.
    • Linux/macOS: Terminal nativo.
    • Windows: PowerShell, Prompt de Comando (CMD) ou ferramentas como PuTTY e Git Bash.
  • Backup de Configuração: Recomendamos fortemente que você tenha uma cópia do arquivo /etc/ssh/sshd_config antes de qualquer alteração.

Aviso de Segurança: Nunca feche sua sessão SSH atual sem testar a nova conexão em uma janela separada. Se houver um erro na configuração das chaves, você perderá o acesso ao servidor.

Geração do par de chaves

O primeiro passo é criar o par de chaves (pública e privada) na sua máquina local (seu computador pessoal). Nunca realize este processo dentro do servidor, pois a chave privada deve permanecer apenas no seu dispositivo.

Para gerar as chaves, abra o terminal (Linux/macOS) ou o PowerShell/CMD (Windows) e execute o seguinte comando:

ssh-keygen -t rsa -b 4096

Durante a execução, o sistema solicitará algumas definições:

  1. Enter file in which to save the key: Pressione Enter para aceitar o caminho padrão (geralmente ~/.ssh/id_rsa).
  2. Enter passphrase: Aqui você pode definir uma senha adicional para proteger a sua chave privada. Se desejar um acesso totalmente automatizado, deixe em branco e pressione Enter.
  3. Enter same passphrase again: Repita a senha (ou pressione Enter novamente).

Ao finalizar, o comando criará dois arquivos na pasta .ssh:

  • id_rsa: Sua chave privada. Trate este arquivo como sua senha mestra; nunca o compartilhe ou envie para ninguém.
  • id_rsa.pub: Sua chave pública. Este é o conteúdo que enviaremos para o servidor Linux/VPS.

Configuração do Servidor

Agora que você já possui o par de chaves gerado em sua máquina local, o próximo passo é transferir a chave pública para o servidor Linux. Este processo permite que o servidor reconheça sua identidade sem a necessidade de uma senha.

Atenção: Certifique-se de que o acesso via senha ainda está ativo durante este passo. Se você configurar a chave incorretamente e desabilitar a senha antes de testar, perderá o acesso ao servidor.

  1. Transferindo a chave pública: Se você estiver utilizando um sistema baseado em Unix (Linux ou macOS), utilize o comando ssh-copy-id para automatizar o processo:
    ssh-copy-id usuario@ip-do-seu-servidor
  2. Método Manual (Windows/Outros): Caso não tenha o comando acima, você deve copiar o conteúdo do seu arquivo id_rsa.pub (local) e colá-lo dentro do arquivo authorized_keys no servidor:
    mkdir -p ~/.ssh
    mkdir -p ~/.ssh && chmod 700 ~/.ssh
    echo "conteúdo_da_sua_chave_publica" >> ~/.ssh/authorized_keys
    chmod 600 ~/.ssh/authorized_keys
  3. Verificação de permissões: É crucial que a pasta .ssh e o arquivo authorized_keys tenham as permissões restritas corretas para que o serviço SSH aceite a conexão por segurança.

Desativação do login por senha

Após garantir que sua chave pública está corretamente instalada no servidor, o próximo passo é configurar o serviço SSH para rejeitar tentativas de autenticação via senha. Isso elimina o risco de ataques de força bruta (brute force) contra o seu usuário.

Atenção: Certifique-se de que você consegue logar com a chave RSA antes de prosseguir. Se você desativar a senha e a chave falhar, você perderá o acesso ao servidor.

  1. Acesse seu servidor via terminal e abra o arquivo de configuração do daemon SSH utilizando um editor de texto (como o nano ou vi):

    Verificação de acesso

    Após realizar as alterações no arquivo de configuração do SSH, é fundamental validar se a chave privada está funcionando corretamente antes de encerrar sua sessão atual. Nunca feche sua conexão ativa sem testar o novo acesso, pois um erro de configuração pode impedir o login remoto no servidor.

    Siga estes passos para garantir que tudo esteja operando conforme o esperado:

    1. Abra um novo terminal: Não utilize a janela onde você editou o arquivo sshd_config. Abra uma nova aba ou uma nova instância do terminal no seu computador local.
    2. Tente o acesso via SSH: Utilize o comando padrão especificando o caminho da sua chave privada (caso ela não esteja na pasta padrão .ssh):
      ssh -i ~/.ssh/id_rsa usuario@ip-do-seu-servidor
    3. Confirme o comportamento:
      • Sucesso: Se o terminal solicitar o passphrase (caso você tenha definido uma senha para a chave) e entrar diretamente no prompt do servidor, a configuração está perfeita.
      • Falha: Se o servidor solicitar a senha do usuário, o método de autenticação por senha ainda está ativo ou a chave pública não foi aceita.

    Se o acesso for negado e você não conseguir logar, utilize a sessão que ainda está aberta no servidor para revisar as permissões do arquivo authorized_keys e o status do serviço sshd.

Troubleshooting

Se você perder o acesso ao servidor após desabilitar o login por senha, não entre em pânico. O erro mais comum é a chave pública não ter sido inserida corretamente no arquivo authorized_keys ou permissões de pasta incorretas.

Siga estes passos para diagnosticar e resolver problemas:

  1. Acesso de Emergência: Se o SSH via chave falhar, utilize o Console Web (VNC) disponível no painpos da Toda Solução. Ele permite acesso direto ao terminal ignorando as configurações de rede e SSH.
  2. Verificação de Permissões: O SSH é extremamente rigoroso com permissões. No servidor, certifique-se de que os diretórios e arquivos seguem este padrão:
    • Pasta .ssh: chmod 700 ~/.ssh
    • Arquivo authorized_keys: chmod 600 ~/.ssh/authorized_keys
    • Proprietário: Certifique-se de que o usuário é o dono dos arquivos (chown -R usuario:usuario ~/.ssh).
  3. Logs do Servidor: Para identificar o motivo exato da rejeição, verifique os logs de autenticação do sistema Linux:
    tail -f /var/log/auth.log
    (Em sistemas baseados em RedHat/CentOS, utilize /var/log/secure). Procure por mensagens como "Authentication refused" ou "Permission denied".
  4. Configuração do SSHD: Se o erro persistir, verifique se a diretiva PubkeyAuthentication está definida como yes no arquivo /etc/ssh/sshd_config.

 

Compartilhar: Link copiado!
Esse tutorial foi útil?

Comentários (0)

Seja o primeiro a comentar.

Deixe seu comentário

Seu comentário será analisado antes de ser publicado.

0/2000