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/
| Ficheiro | Finalidade |
|---|---|
id_rsa | Chave privada RSA padrão |
id_rsa.pub | Chave pública RSA correspondente |
id_ecdsa | Chave privada ECDSA |
id_ed25519 | Chave privada Ed25519 (recomendada) |
id_*.pub | Contraparte de chave pública para qualquer chave privada |
authorized_keys | Lista de chaves públicas autorizadas a iniciar sessão nesta conta |
known_hosts | Impressões digitais de servidores previamente conectados |
config | Configuraçã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/
| Ficheiro | Finalidade |
|---|---|
ssh_host_rsa_key | Chave privada de host RSA |
ssh_host_rsa_key.pub | Chave pública de host RSA |
ssh_host_ecdsa_key | Chave privada de host ECDSA |
ssh_host_ecdsa_key.pub | Chave pública de host ECDSA |
ssh_host_ed25519_key | Chave privada de host Ed25519 |
ssh_host_ed25519_key.pub | Chave 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@hostUsando ~/.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_keyCom 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 remotoscp— cópia segura de arquivosrsync— sincronização de arquivos sobre SSHgit— 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_keysEste 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/configTabela de Referência de Permissões
| Caminho | Permissão Obrigatória | Octal |
|---|---|---|
~/.ssh/ | Leitura/escrita/execução apenas do proprietário | 700 |
~/.ssh/authorized_keys | Leitura/escrita apenas do proprietário | 600 |
~/.ssh/id_rsa (chave privada) | Leitura/escrita apenas do proprietário | 600 |
~/.ssh/id_rsa.pub (chave pública) | Leitura do proprietário, leitura de outros | 644 |
~/.ssh/config | Leitura/escrita apenas do proprietário | 600 |
Para corrigir permissões num único comando:
chmod 700 ~/.ssh && chmod 600 ~/.ssh/* && chmod 644 ~/.ssh/*.pubGerando 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_ed25519Você 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 -DCopiar 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-hostIsto 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@hostPara ainda mais detalhes:
ssh -vvv user@hostEsta 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 -fVerificar 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_keysMelhores 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/null4. 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-passwordReinicie sshd após as alterações:
systemctl restart sshd5. 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ção | Tipo | Finalidade |
|---|---|---|
~/.ssh/id_ed25519 | Chave privada do utilizador | Autenticação do cliente |
~/.ssh/id_ed25519.pub | Chave pública do utilizador | Distribuída para servidores |
~/.ssh/authorized_keys | Chaves públicas autorizadas | Controla quem pode fazer login |
~/.ssh/known_hosts | Impressões digitais do servidor | Previne ataques MITM |
~/.ssh/config | Configuração do cliente | Definições por anfitrião |
/etc/ssh/ssh_host_* | Chaves do anfitrião | Identidade do servidor |
/etc/ssh/sshd_config | Configuração do daemon | Definiçõ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_keyscontrola 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-agentpara 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.
em todos os serviços de alojamento