Como configurar SSH sem senha para servidores Linux

1. Introdução ao SSH e Autenticação por Chaves

O SSH (Secure Shell) é o protocolo padrão para administração remota de servidores Linux. Tradicionalmente, a autenticação ocorre por senha, mas esse método apresenta vulnerabilidades significativas: senhas fracas podem ser quebradas por ataques de força bruta, e a automação de tarefas (como backups ou deploys) exige armazenamento inseguro de credenciais.

A autenticação por chaves SSH resolve esses problemas utilizando criptografia assimétrica. O sistema funciona com um par de chaves:
- Chave privada: mantida em segredo no cliente (sua máquina local)
- Chave pública: instalada no servidor remoto

Quando você tenta se conectar, o servidor desafia o cliente a provar que possui a chave privada correspondente à chave pública armazenada. Esse processo é matematicamente seguro e não transmite a chave privada pela rede.

As vantagens incluem:
- Eliminação de senhas fracas e ataques de força bruta
- Possibilidade de automação segura (scripts, CI/CD)
- Conexões mais rápidas (sem espera por digitação de senha)
- Controle granular de acesso por chave

2. Gerando o Par de Chaves SSH no Cliente

O primeiro passo é gerar o par de chaves no seu computador local (cliente). O comando ssh-keygen é a ferramenta padrão para isso.

Para gerar uma chave RSA de 4096 bits (recomendado para compatibilidade máxima):

ssh-keygen -t rsa -b 4096 -C "seu-email@exemplo.com"

Para maior segurança e performance, prefira o algoritmo Ed25519 (mais moderno e seguro):

ssh-keygen -t ed25519 -C "seu-email@exemplo.com"

O comando solicitará:
1. Localização do arquivo: pressione Enter para aceitar o padrão (~/.ssh/id_ed25519 ou ~/.ssh/id_rsa)
2. Passphrase: uma senha adicional para proteger a chave privada (opcional, mas recomendada)

Após a execução, verifique os arquivos gerados:

ls -la ~/.ssh/

Você verá dois arquivos:
- id_ed25519 (ou id_rsa): chave privada (nunca compartilhe!)
- id_ed25519.pub (ou id_rsa.pub): chave pública (pode ser distribuída)

3. Copiando a Chave Pública para o Servidor Remoto

Existem duas formas principais de instalar a chave pública no servidor.

Método 1: Usando ssh-copy-id (recomendado)

Este utilitário copia automaticamente a chave pública para o local correto:

ssh-copy-id usuario@servidor-remoto

Você precisará digitar a senha do usuário remoto uma última vez. O comando:
1. Conecta ao servidor via SSH (com senha)
2. Adiciona o conteúdo de ~/.ssh/id_*.pub ao arquivo ~/.ssh/authorized_keys do servidor
3. Ajusta as permissões automaticamente

Método 2: Manual

Se ssh-copy-id não estiver disponível, faça manualmente:

cat ~/.ssh/id_ed25519.pub | ssh usuario@servidor-remoto "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Verificando Permissões

No servidor remoto, as permissões devem estar corretas para que o SSH aceite a chave:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

4. Configurações Essenciais no Servidor (sshd_config)

O arquivo de configuração do servidor SSH (/etc/ssh/sshd_config) controla como as conexões são autenticadas. Edite-o com privilégios de root:

sudo nano /etc/ssh/sshd_config

Verifique ou adicione as seguintes linhas:

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes

Explicação:
- PubkeyAuthentication yes: ativa autenticação por chave pública
- PasswordAuthentication no: desativa login por senha (recomendado após testar)
- ChallengeResponseAuthentication no: desativa métodos alternativos de senha

Para restringir quais usuários podem usar chaves:

AllowUsers usuario1 usuario2

Após alterar, reinicie o serviço SSH:

sudo systemctl restart sshd

Atenção: nunca desative PasswordAuthentication sem antes testar a conexão por chave!

5. Testando a Conexão e Resolvendo Problemas Comuns

Teste a conexão sem senha:

ssh usuario@servidor-remoto

Se funcionar, você estará logado diretamente. Caso contrário, use o modo verbose para depuração:

ssh -v usuario@servidor-remoto

Para ainda mais detalhes, use -vvv.

Problemas Frequentes e Soluções

1. Permissões incorretas no servidor:

# Corrigir no servidor remoto
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/id_*

2. Chave pública errada ou não encontrada:
Verifique se o conteúdo de ~/.ssh/authorized_keys corresponde exatamente à sua chave pública.

3. SELinux bloqueando:

# Verificar contexto SELinux
restorecon -R -v ~/.ssh

4. AppArmor ativo:
Verifique logs em /var/log/syslog ou /var/log/auth.log.

5. Arquivo sshd_config com erro:
Teste a sintaxe antes de reiniciar:

sudo sshd -t

6. Gerenciando Múltiplas Chaves e Servidores

Quando você gerencia vários servidores, o arquivo ~/.ssh/config simplifica as conexões.

Exemplo de configuração:

Host servidor-producao
    HostName 192.168.1.100
    User admin
    Port 2222
    IdentityFile ~/.ssh/chave_producao

Host servidor-teste
    HostName 192.168.1.200
    User dev
    IdentityFile ~/.ssh/chave_teste

Agora você pode conectar apenas com:

ssh servidor-producao

Usando ssh-agent para Passphrase

Se sua chave privada tem passphrase, use o agente SSH para evitar digitá-la repetidamente:

# Iniciar o agente
eval "$(ssh-agent -s)"

# Adicionar chave
ssh-add ~/.ssh/id_ed25519

O agente manterá a chave descriptografada na memória durante a sessão.

7. Boas Práticas de Segurança e Manutenção

Protegendo a Chave Privada

  • Mantenha permissões restritas: chmod 600 ~/.ssh/id_*
  • Nunca compartilhe a chave privada por e-mail, mensagens ou repositórios
  • Considere usar um gerenciador de senhas ou hardware token (YubiKey)
  • Faça backup seguro da chave privada em local criptografado

Rotação de Chaves

Troque as chaves periodicamente (a cada 6-12 meses):

# Gerar nova chave
ssh-keygen -t ed25519 -f ~/.ssh/nova_chave

# Copiar para servidores
ssh-copy-id -i ~/.ssh/nova_chave.pub usuario@servidor

# Testar
ssh -i ~/.ssh/nova_chave usuario@servidor

# Remover chave antiga do servidor
ssh usuario@servidor "sed -i '/chave_antiga/d' ~/.ssh/authorized_keys"

Revogação de Acesso

Para remover acesso de uma chave comprometida ou de ex-funcionário:

# No servidor, editar authorized_keys e remover a linha correspondente
nano ~/.ssh/authorized_keys

Monitoramento

Verifique regularmente os logs de autenticação:

sudo tail -f /var/log/auth.log | grep sshd

Procure por tentativas de conexão suspeitas ou falhas de autenticação.

Referências