Poupe 15% em todos os serviços de alojamento

Teste as suas habilidades e obtenha Desconto em qualquer plano

Utilizar o código: Skills Começar a trabalhar
Secções
Administração DNS Linux

Onde as Chaves SSH são Armazenadas no Linux — E Como Gerenciá-las com Segurança

SSH (Secure Shell) é uma das ferramentas mais críticas no ecossistema Linux. Administradores de sistemas, desenvolvedores e engenheiros DevOps dependem dela diariamente para acesso remoto a servidores, transferências seguras de arquivos, automação de implementação e gerenciamento de infraestrutura. Embora a maioria dos utilizadores interaja com SSH através de um simples comando de terminal, a verdadeira espinha dorsal de segurança reside em pares de chaves SSH — credenciais criptográficas que permitem autenticação sem palavra-passe, fluxos de trabalho automatizados e controlo de acesso reforçado.

Quer esteja a gerir uma única instância de VPS Hosting ou a orquestrar acesso em dezenas de Servidores Dedicados, compreender exatamente onde as chaves SSH são armazenadas — e como gerenciá-las adequadamente — não é opcional. É um requisito de segurança fundamental.

Este guia cobre tudo: localizações padrão de armazenamento de chaves, chaves de anfitrião em todo o sistema, configurações personalizadas, requisitos de permissão e melhores práticas para gerenciamento seguro de chaves.

O que são Chaves SSH e Por Que Importam?

As chaves SSH usam criptografia assimétrica para autenticar utilizadores e servidores. Cada par de chaves consiste em:

  • Chave privada — mantida secreta na máquina cliente, nunca partilhada
  • Chave pública — colocada no servidor remoto para verificar identidade

Quando se conecta a um servidor, SSH usa um handshake criptográfico para verificar que possui a chave privada correspondente à chave pública no servidor — sem nunca transmitir a chave privada em si. Isto é fundamentalmente mais seguro do que autenticação baseada em palavra-passe.

Localização Padrão de Armazenamento de Chaves SSH (Chaves de Utilizador)

Para qualquer utilizador Linux padrão, as chaves SSH são armazenadas num diretório oculto dentro da pasta inicial:

~/.ssh/

Isto expande para o caminho completo:

/home/username/.ssh/

Para o utilizador root especificamente:

/root/.ssh/

Ficheiros Comuns Dentro de ~/.ssh/

FicheiroFinalidade
id_rsaChave privada RSA padrão
id_rsa.pubChave pública RSA correspondente
id_ecdsaChave privada ECDSA
id_ed25519Chave privada Ed25519 (recomendada)
id_*.pubContraparte de chave pública para qualquer chave privada
authorized_keysLista de chaves públicas autorizadas a iniciar sessão nesta conta
known_hostsImpressões digitais de servidores previamente conectados
configConfiguração do cliente SSH específica do utilizador

Quando executa ssh-keygen, as chaves são escritas neste diretório por padrão, a menos que especifique explicitamente um caminho diferente durante a geração de chaves.

Localizações de Chaves SSH em Todo o Sistema (Chaves de Host)

Além das chaves de utilizador, o daemon SSH (sshd) — o componente do lado do servidor — mantém o seu próprio conjunto de chaves de host. Estas são armazenadas em todo o sistema em:

/etc/ssh/

Ficheiros de Chave de Host em /etc/ssh/

FicheiroFinalidade
ssh_host_rsa_keyChave privada de host RSA
ssh_host_rsa_key.pubChave pública de host RSA
ssh_host_ecdsa_keyChave privada de host ECDSA
ssh_host_ecdsa_key.pubChave pública de host ECDSA
ssh_host_ed25519_keyChave privada de host Ed25519
ssh_host_ed25519_key.pubChave pública de host Ed25519

Estas chaves de host servem um propósito diferente das chaves de utilizador. Quando um cliente se conecta a um servidor pela primeira vez, o servidor apresenta a sua chave pública de host. O cliente armazena esta impressão digital em ~/.ssh/known_hosts. Em conexões subsequentes, SSH verifica se a impressão digital corresponde — protegendo contra ataques man-in-the-middle.

> Importante: As chaves de host são geradas automaticamente durante a instalação do servidor SSH. Nunca deverá precisar de as criar manualmente, mas deverá saber onde se encontram para fins de auditoria e cópia de segurança.

Localizações Personalizadas de Chaves SSH

Você não está restrito ao diretório padrão ~/.ssh/. As chaves SSH podem ser geradas e armazenadas em qualquer lugar do sistema de ficheiros. Para usar uma chave armazenada em um local não padrão, especifique-a explicitamente:

ssh -i /path/to/custom_key user@host

Usando ~/.ssh/config para Múltiplas Chaves

Gerenciar múltiplos servidores, projetos ou contas de utilizador fica muito mais limpo com um ficheiro ~/.ssh/config adequadamente configurado. Isto permite que você defina configurações por anfitrião, incluindo qual chave usar:

Host production-server
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/production_ed25519

Host staging-server
    HostName 203.0.113.20
    User deploy
    IdentityFile ~/.ssh/staging_ed25519

Host github.com
    User git
    IdentityFile ~/.ssh/github_key

Com esta configuração, executar ssh production-server usa automaticamente a chave correta sem quaisquer sinalizadores adicionais.

Como as Chaves SSH São Usadas: Cliente vs. Servidor

Conexões de Saída (Lado do Cliente)

Quando você inicia uma conexão SSH, o cliente SSH procura por chaves privadas em ~/.ssh/ por padrão. Essas chaves são usadas para autenticá-lo no servidor remoto.

Ferramentas que usam chaves de cliente SSH incluem:

  • ssh — acesso direto ao shell remoto
  • scp — cópia segura de arquivos
  • rsync — sincronização de arquivos sobre SSH
  • git — ao usar repositórios remotos baseados em SSH

Conexões de Entrada (Lado do Servidor)

No servidor, SSH verifica um arquivo específico para determinar quais usuários estão autorizados a se conectar:

~/.ssh/authorized_keys

Este arquivo contém uma chave pública por linha. Cada entrada concede ao detentor da chave privada correspondente permissão para fazer login como esse usuário.

Exemplo prático: Se o usuário alice quer fazer SSH em um servidor como usuário webadmin, a chave pública de Alice deve estar presente em /home/webadmin/.ssh/authorized_keys — não no diretório inicial de Alice naquele servidor.

Permissões de Ficheiros — Crítico para a Segurança SSH

É aqui que muitos administradores cometem erros dispendiosos. SSH é deliberadamente rigoroso sobre permissões de ficheiros. Se as permissões forem demasiado abertas, SSH irá recusar silenciosamente a utilização das suas chaves ou rejeitar tentativas de login completamente.

Definições de Permissão Obrigatórias

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

Tabela de Referência de Permissões

CaminhoPermissão ObrigatóriaOctal
~/.ssh/Leitura/escrita/execução apenas do proprietário700
~/.ssh/authorized_keysLeitura/escrita apenas do proprietário600
~/.ssh/id_rsa (chave privada)Leitura/escrita apenas do proprietário600
~/.ssh/id_rsa.pub (chave pública)Leitura do proprietário, leitura de outros644
~/.ssh/configLeitura/escrita apenas do proprietário600

Para corrigir permissões num único comando:

chmod 700 ~/.ssh && chmod 600 ~/.ssh/* && chmod 644 ~/.ssh/*.pub

Gerando Chaves SSH com Segurança

Sempre prefira Ed25519 em vez de RSA para novas chaves. Ed25519 oferece segurança mais forte com tamanhos de chave menores e desempenho mais rápido.

ssh-keygen -t ed25519 -C "your_email@example.com"

Para sistemas legados que requerem RSA, use pelo menos 4096 bits:

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Sempre defina uma frase-passe quando solicitado. Uma frase-passe encripta a chave privada no disco, portanto, mesmo que um atacante ganhe acesso ao seu sistema de ficheiros, não pode usar a chave sem a frase-passe.

Gerenciar Chaves com ssh-agent

Inserir sua frase de acesso sempre que você usa uma chave SSH torna-se impraticável. ssh-agent resolve isso armazenando em cache chaves descriptografadas na memória durante sua sessão.

Iniciando ssh-agent e Adicionando uma Chave

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Você será solicitado a inserir a frase de acesso uma vez. Depois disso, as operações SSH usam a chave em cache automaticamente.

Comandos Úteis do ssh-agent

# List currently loaded keys
ssh-add -l

# Remove a specific key from the agent
ssh-add -d ~/.ssh/mykey

# Remove all keys from the agent
ssh-add -D

Copiar Chaves Públicas para Servidores Remotos

A forma mais fácil de instalar a sua chave pública num servidor remoto é com ssh-copy-id:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@remote-host

Isto acrescenta a sua chave pública a ~/.ssh/authorized_keys no servidor remoto e define as permissões corretas automaticamente.

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

cat ~/.ssh/id_ed25519.pub | ssh user@remote-host "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Auditoria e Depuração de Problemas de Chaves SSH

Registo Detalhado de Conexão

Quando a autenticação SSH falha, o modo verboso revela exatamente o que está acontecendo:

ssh -v user@host

Para ainda mais detalhes:

ssh -vvv user@host

Esta saída mostra quais ficheiros de identidade foram tentados, se o agente foi consultado e onde a autenticação falhou.

Verificar o Registo SSH do Lado do Servidor

No servidor remoto, os eventos de autenticação SSH são registados em:

# Debian/Ubuntu
tail -f /var/log/auth.log

# CentOS/RHEL/Fedora
tail -f /var/log/secure

# Systems using journald
journalctl -u sshd -f

Verificar o Seu Ficheiro authorized_keys

# Check the file exists and has correct permissions
ls -la ~/.ssh/authorized_keys

# View its contents
cat ~/.ssh/authorized_keys

# Count how many keys are authorized
grep -c "ssh-" ~/.ssh/authorized_keys

Melhores Práticas de Segurança de Chaves SSH

A gestão adequada de chaves vai além de saber onde os ficheiros estão armazenados. Siga estas práticas em cada sistema que gere:

1. Use Uma Chave Por Propósito

Nunca reutilize a mesma chave SSH em diferentes ambientes, clientes ou projetos. Use chaves separadas para acesso pessoal, automação de implementação e acesso partilhado da equipa.

2. Rode Chaves Regularmente

Trate as chaves SSH como palavras-passe — rode-as periodicamente, especialmente após saídas de membros da equipa ou suspeitas de comprometimento.

3. Audite authorized_keys Ficheiros

Revise regularmente quais as chaves públicas autorizadas em cada servidor. Remova quaisquer chaves que pertençam a antigos funcionários, automação obsoleta ou fontes não reconhecidas:

# Find all authorized_keys files on a system
find / -name "authorized_keys" 2>/dev/null

4. Desative a Autenticação por Palavra-Passe

Depois de as chaves SSH estarem configuradas, desative completamente o login SSH baseado em palavra-passe em /etc/ssh/sshd_config:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password

Reinicie sshd após as alterações:

systemctl restart sshd

5. Restrinja a Utilização de Chaves Root

Evite usar chaves SSH root em múltiplos ambientes. Em vez disso, use contas de utilizador ativadas por sudo com chaves individuais.

6. Use Autenticação Baseada em Certificados para Escala

Para infraestruturas grandes, considere certificados SSH (através de uma Autoridade de Certificados SSH) em vez de gerir entradas authorized_keys individuais. Isto simplifica dramaticamente a gestão de acesso em muitos servidores.

Chaves SSH em Ambientes Cloud e Hosting

Ao implementar servidores em ambientes cloud ou hosting gerenciado, a gestão de chaves SSH torna-se ainda mais crítica. A maioria das plataformas — incluindo provedores de VPS Hosting — permite injetar uma chave pública no momento do provisionamento, dando-lhe acesso seguro imediato sem nunca definir uma senha.

Para equipas que gerem múltiplos ambientes, considere associar a sua estratégia de chaves SSH com uma configuração estruturada de Painéis de Controlo VPS, que pode simplificar a gestão de utilizadores e controlo de acesso em toda a sua infraestrutura.

Se está a executar aplicações web ou serviços que requerem comunicação segura além de SSH, associar a configuração do seu servidor com Certificados SSL devidamente configurados garante encriptação de ponta a ponta para todo o tráfego — não apenas acesso administrativo.

Para equipas que dependem de Email Hosting juntamente com a sua infraestrutura de servidores, a gestão de chaves SSH estende-se à segurança dos sistemas que lidam com o seu correio — outra razão pela qual a higiene consistente de chaves em todos os servidores é importante.

Referência Rápida: Localizações de Ficheiros de Chave SSH

LocalizaçãoTipoFinalidade
~/.ssh/id_ed25519Chave privada do utilizadorAutenticação do cliente
~/.ssh/id_ed25519.pubChave pública do utilizadorDistribuída para servidores
~/.ssh/authorized_keysChaves públicas autorizadasControla quem pode fazer login
~/.ssh/known_hostsImpressões digitais do servidorPrevine ataques MITM
~/.ssh/configConfiguração do clienteDefinições por anfitrião
/etc/ssh/ssh_host_*Chaves do anfitriãoIdentidade do servidor
/etc/ssh/sshd_configConfiguração do daemonDefinições do servidor SSH

Conclusão

Compreender onde as chaves SSH são armazenadas no Linux — e gerenciá-las com disciplina — é uma das habilidades mais importantes para qualquer pessoa que trabalhe com servidores, seja você um desenvolvedor solo ou parte de uma grande equipe de operações.

Para resumir os principais pontos:

  • Chaves de utilizador vivem em ~/.ssh/ e são usadas para autenticação do lado do cliente
  • Chaves de anfitrião vivem em /etc/ssh/ e identificam o servidor para clientes que se conectam
  • authorized_keys controla o acesso de entrada — audite-o regularmente
  • As permissões de ficheiro são inegociáveis — permissões incorretas quebram SSH silenciosamente
  • Ed25519 é o tipo de chave preferido para geração de novas chaves
  • Sempre use frases-passe e ssh-agent para gestão diária de chaves
  • Rode e audite chaves como parte da sua higiene de segurança regular

Em sistemas de produção — quer esteja a executar Servidores Dedicados ou infraestrutura partilhada — a má gestão de chaves SSH é um dos vetores mais comuns para acesso não autorizado. O investimento de tempo em acertar isto compensa em segurança, confiabilidade e tranquilidade.

Trate as suas chaves SSH com o mesmo cuidado que daria a qualquer credencial crítica. Porque é exatamente isso que são.