Chaves SSH: criando, configurando e usando

1. Fundamentos das Chaves SSH

Chaves SSH são pares de arquivos criptográficos que permitem autenticação segura entre máquinas sem o uso de senhas tradicionais. O sistema funciona com dois componentes: uma chave privada (mantida em segredo pelo usuário) e uma chave pública (copiada para servidores remotos). Quando você tenta se conectar, o servidor desafia o cliente a provar que possui a chave privada correspondente à pública registrada, estabelecendo uma conexão criptografada.

A principal vantagem sobre senhas é dupla: elimina ataques de força bruta contra senhas e permite automação de tarefas — scripts podem executar comandos remotos sem intervenção humana. Entre os algoritmos disponíveis, a escolha atual recai sobre:

  • Ed25519 (recomendado): rápido, seguro e chaves curtas (256 bits)
  • ECDSA: bom equilíbrio entre segurança e desempenho
  • RSA: amplamente compatível, mas requer 4096 bits para segurança equivalente

Para novas implantações, prefira Ed25519. Use RSA apenas por compatibilidade com sistemas legados.

2. Gerando Pares de Chaves com ssh-keygen

O comando ssh-keygen é a ferramenta padrão para criação de chaves. Sua sintaxe básica:

ssh-keygen -t ed25519 -C "meu@email.com"

Isso gera dois arquivos em ~/.ssh/: id_ed25519 (privada) e id_ed25519.pub (pública). O parâmetro -C adiciona um comentário útil para identificar a chave.

Para personalizar a geração:

ssh-keygen -t rsa -b 4096 -f ~/.ssh/servidor_producao -C "chave servidor produção"

Aqui especificamos:
- -t rsa: tipo do algoritmo
- -b 4096: tamanho da chave em bits
- -f ~/.ssh/servidor_producao: caminho e nome do arquivo de saída

Durante a execução, você pode definir uma frase secreta (passphrase) que protege a chave privada. Sem ela, qualquer pessoa com acesso ao arquivo pode usar a chave.

Para verificar as chaves geradas:

ls -la ~/.ssh/
ssh-keygen -l -f ~/.ssh/id_ed25519

O segundo comando exibe a impressão digital (fingerprint) da chave, útil para confirmar que é a chave correta.

3. Gerenciando Múltiplas Chaves no Diretório ~/.ssh/

À medida que você gerencia vários servidores, ter múltiplas chaves organizadas é essencial. Nomeie arquivos de forma descritiva:

  • id_ed25519 — chave pessoal padrão
  • id_rsa_servidor_web — chave RSA específica para servidor web
  • id_ed25519_github — chave para GitHub

Para organizar, crie subdiretórios:

mkdir -p ~/.ssh/empresas
ssh-keygen -t ed25519 -f ~/.ssh/empresas/cliente_a -C "cliente A"

As permissões dos arquivos são críticas para segurança:

chmod 600 ~/.ssh/id_ed25519          # privada: somente leitura para o dono
chmod 644 ~/.ssh/id_ed25519.pub      # pública: leitura para todos
chmod 700 ~/.ssh/                     # diretório: acesso apenas ao dono

Para backup seguro, exporte apenas a chave privada protegida por frase secreta, nunca a pública (que é facilmente regenerável).

4. Copiando Chaves Públicas para Servidores

A maneira mais simples de instalar sua chave pública em um servidor remoto é com ssh-copy-id:

ssh-copy-id -i ~/.ssh/minhachave.pub usuario@servidor.com

Esse comando adiciona automaticamente sua chave ao arquivo ~/.ssh/authorized_keys no servidor, criando o diretório e o arquivo com permissões corretas.

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

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

Ou, em duas etapas:

cat ~/.ssh/minhachave.pub
# copie o conteúdo
ssh usuario@servidor.com
echo "chave_copiada" >> ~/.ssh/authorized_keys

Para verificar se a instalação funcionou:

ssh -i ~/.ssh/minhachave usuario@servidor.com

Se a conexão for estabelecida sem solicitar senha, a configuração está correta.

5. Configurando o Cliente SSH com ~/.ssh/config

O arquivo ~/.ssh/config simplifica conexões frequentes. Estrutura básica:

Host servidor-web
    HostName 192.168.1.100
    User admin
    IdentityFile ~/.ssh/servidor_web
    Port 2222

Agora, para conectar, basta digitar ssh servidor-web — o cliente SSH aplica automaticamente as configurações definidas.

Exemplo com múltiplos servidores e chaves diferentes:

Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_github

Host servidor-producao
    HostName 10.0.0.50
    User deploy
    IdentityFile ~/.ssh/empresas/cliente_a
    Port 22

Host servidor-dev
    HostName dev.internal.com
    User devuser
    IdentityFile ~/.ssh/id_ed25519
    ForwardAgent yes
    ServerAliveInterval 60

Opções avançadas úteis:
- ForwardAgent yes: permite usar chaves locais em conexões subsequentes
- ServerAliveInterval 60: mantém conexão ativa enviando pacotes a cada 60 segundos

6. Automação com Chaves SSH em Scripts

Chaves SSH permitem automação segura de tarefas remotas. Execute comandos sem interação:

ssh usuario@servidor "uptime && df -h"

Para scripts que usam frases secretas, utilize ssh-agent:

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

# Adicionar chave (solicita frase secreta uma vez)
ssh-add ~/.ssh/id_ed25519

# Executar comandos sem redigitar frase secreta
ssh servidor-web "backup.sh"

Script seguro com tratamento de erros:

#!/bin/bash

CHAVE="$HOME/.ssh/servidor_producao"
SERVIDOR="admin@10.0.0.50"

if [ ! -f "$CHAVE" ]; then
    echo "Erro: chave $CHAVE não encontrada" >&2
    exit 1
fi

ssh -i "$CHAVE" "$SERVIDOR" "systemctl status nginx" || {
    echo "Falha ao conectar ou executar comando" >&2
    exit 2
}

Evite expor chaves em logs: nunca passe a chave como argumento direto em comandos registrados. Use variáveis de ambiente ou arquivos de configuração.

7. Solução de Problemas Comuns

Permissões incorretas são a causa mais frequente de falhas. Corrija com:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

Depuração detalhada com -vvv:

ssh -vvv -i ~/.ssh/minhachave usuario@servidor

Isso mostra cada etapa da negociação. Procure por mensagens como:
- debug1: Authentication succeeded: sucesso
- debug1: Permissions 0644 for 'id_ed25519' are too open: permissão incorreta
- debug1: No more authentication methods to try: chave não reconhecida

Chave rejeitada pode ser por alteração do fingerprint do servidor. Verifique ~/.ssh/known_hosts:

ssh-keygen -R servidor.com   # remove entrada antiga
ssh servidor.com              # aceita novo fingerprint

8. Boas Práticas e Segurança

Rotação de chaves: gere novas chaves anualmente ou sempre que suspeitar de comprometimento. Nunca reutilize a mesma chave em múltiplos serviços críticos.

Revogando acesso: remova a chave pública do arquivo authorized_keys no servidor:

ssh usuario@servidor "sed -i '/chave_a_remover/d' ~/.ssh/authorized_keys"

Frases secretas: use frases longas (mínimo 15 caracteres) com combinação de letras, números e símbolos. Configure ssh-agent com timeout:

ssh-add -t 3600 ~/.ssh/id_ed25519   # expira após 1 hora

Isso limpa a chave da memória após o período definido, reduzindo riscos em caso de acesso não autorizado ao terminal.

Referências