Gerenciamento de Chaves SSH: Desafios e Evolução das Abordagens
Explore os desafios do gerenciamento de chaves SSH em larga escala, desde as limitações do arquivo authorized_keys até a evolução para soluções como SSH CA e PAM. Descubra como otimizar a segurança e a eficiência em sua infraestrutura.
MundiX News·09 de julho de 2026·10 min de leitura·👁 1 views
Em infraestruturas com centenas ou milhares de servidores e um número considerável de administradores, a contagem de chaves SSH ativas pode facilmente chegar a dezenas de milhares. Por padrão, essas chaves não possuem prazo de validade, o que leva ao acúmulo e obsolescência ao longo do tempo. Estudos indicam que em grandes empresas, até 90% das chaves podem estar em desuso e sem gerenciamento, enquanto uma parte das chaves ativas concede acesso no nível root. A ausência de um gerenciamento centralizado agrava o problema: ao demitir um funcionário, seus acessos podem ser esquecidos, permitindo que ele continue a se conectar aos sistemas. Consequentemente, os administradores se deparam com a tarefa árdua de controlar e atualizar as credenciais de autorização.
Inicialmente, vamos analisar um dos métodos de autenticação mais comuns: a autenticação por chave pública (Public Key Authentication - PKA). Ela ganhou popularidade devido à sua simplicidade, alta resistência criptográfica e à ausência da necessidade de transmitir senhas pela rede. Nas sistemas modernos, o pacote OpenSSH é o padrão de implementação. Por padrão, ele autentica o usuário usando a chave pública, que deve residir no arquivo ~/.ssh/authorized_keys no servidor de destino. Cada linha contém uma chave com opções de acesso. Ao tentar uma conexão, o daemon SSH (sshd) compara os dados apresentados pelo cliente com os registros armazenados e, em caso de correspondência, permite o acesso. A principal dificuldade operacional reside no controle. Com um grande número de usuários, adicionar e revogar seus direitos deve ser feito manualmente. A troca de chaves exige a edição do arquivo authorized_keys em cada máquina – um processo extremamente trabalhoso e propenso a erros humanos. O parâmetro expiry-time pode simplificar um pouco a tarefa, permitindo limitar o tempo de vida da chave. Para definir uma data exata de desativação, utiliza-se a seguinte sintaxe: expiry-time="20261231" ssh-ed25519 AAAAZenZeN0ttIIN1NTENAAAAI… geralt@pc. No entanto, isso não resolve o problema de sincronização e gerenciamento. A proibição completa de acesso geralmente se resume à exclusão física da linha desejada do arquivo authorized_keys em todos os servidores. Para economizar tempo no gerenciamento de chaves no OpenSSH, existe o mecanismo AuthorizedKeysCommand. Este parâmetro do arquivo de configuração sshd_config especifica um comando que retorna dinamicamente a lista de chaves permitidas em vez de ler um arquivo estático. O servidor solicita informações de uma fonte externa – mais comumente um banco de dados onde as chaves públicas estão armazenadas. Com essa abordagem, o administrador precisa apenas remover ou bloquear a chave no repositório central, e ela imediatamente deixa de funcionar em todos os nós da infraestrutura.
O desenvolvimento de tecnologias de nuvem impulsionou o surgimento de novas abordagens para o gerenciamento de chaves, como soluções de Gerenciamento de Acesso Privilegiado (Privileged Access Management - PAM) e Acesso com Confiança Zero (Zero Trust Access). Soluções comuns incluem Teleport, Boundary, Delinea ou CyberArk. Elas combinam um repositório centralizado, interface web e ferramentas de auditoria de sessão. Esses sistemas permitem o abandono de chaves SSH permanentes. Em vez de sua distribuição manual, ao usuário é emitido automaticamente um certificado de sessão de curta duração após a autenticação via SSO (Single Sign-On). Como resultado, os administradores obtêm um portal de gerenciamento unificado e podem revogar direitos de acesso a qualquer momento através da revogação da certificação. A aplicação da combinação de PAM e SSO simplifica significativamente o gerenciamento em larga escala, mas exige uma integração robusta com a infraestrutura existente. A Infraestrutura de Chave Pública (Public Key Infrastructure - PKI) é um sistema de gerenciamento de certificados digitais que garante a autenticidade dos participantes com base na confiança em um único centro de certificação. No SSH, esse modelo é adaptado pela assinatura de identificadores de usuários e hosts por um Centro de Certificação confiável. Uma nova abordagem surgiu devido às dificuldades de escalabilidade: o SSH CA (Certificate Authority) permite substituir o armazenamento de milhares de chaves nos servidores por uma opção mais conveniente – controle centralizado e revogação de direitos após o vencimento. No OpenSSH, um certificado é uma chave pública assinada pela chave privada do CA e equipada com metadados – uma lista de nomes de usuários ou hosts permitidos. No lado do servidor ou cliente, a confiança nas chaves públicas do CA é configurada. A verificação de hosts é realizada da seguinte forma: a chave pública do CA é inserida no arquivo known_hosts com o marcador @cert-authority ou através do arquivo ssh_config. O OpenSSH suporta dois tipos de certificados: de usuário e de host. O primeiro autentica o usuário no servidor, especificando os logins permitidos. Ao usar o segundo, o servidor apresenta o certificado de host ao cliente para confirmar sua autenticidade e garantir a proteção da conexão contra interceptação. A ideia principal em ambos os casos é que o servidor e o cliente confiam não em uma lista de chaves específicas, mas na chave do CA e na assinatura do certificado. Ao se conectar, eles trocam certificados e verificam se a assinatura foi feita por um CA confiável e se o próprio documento ainda não expirou. A principal vantagem dos certificados reside no controle centralizado e na limitação do tempo de vida. Os metadados podem definir explicitamente o período de validade, tornando a chave automaticamente temporária.
Para a implantação de um centro de certificação próprio, é necessário gerar um par de chaves CA – para assinar certificados de usuário e de host: ssh-keygen -t ed25519 -f ~/.ssh/ca_user. O flag -t especifica o tipo de algoritmo de criptografia, e -f define o caminho do arquivo e seu nome. A chave privada ca_user permanece no servidor de automação (ou na máquina do administrador), e a chave pública ca_user.pub é copiada para os servidores de destino no diretório /etc/ssh/ca_user.pub. Em seguida, no arquivo de configuração do servidor /etc/ssh/sshd_config, a diretiva TrustedUserCAKeys /etc/ssh/ca_user.pub é configurada. Após isso, o servidor começará a confiar em todas as chaves assinadas por este centro de certificação. Para que as alterações entrem em vigor, é necessário reiniciar o serviço SSH: sudo systemctl restart ssh. A concessão de acesso ocorre quando o usuário fornece sua chave pública, que é assinada pela chave privada do CA: ssh-keygen -s ca_key -I root -n root id_ed25519.pub. O flag -s indica o caminho para a chave CA, -I define um identificador interno para o certificado (Key ID para logging), e -n especifica a lista de contas permitidas (logins do sistema). Como resultado, é criado o arquivo de certificado id_ed25519-cert.pub. O usuário precisa apenas colocá-lo no mesmo diretório de sua chave privada – o OpenSSH o detectará e aplicará automaticamente durante a conexão. Após configurar a confiança no CA, a administração se resume exclusivamente à emissão e revogação de certificados, eliminando a necessidade de distribuir manualmente as chaves dos usuários pelos servidores. O uso de criptografia robusta também permite o abandono completo de senhas, o que aumenta significativamente o nível geral de segurança da infraestrutura. Os certificados possuem um ciclo de vida estritamente limitado. Ao criá-los através da utilidade ssh-keygen, é possível definir o período de validade usando o flag -V [início_validade]:[fim_validade]. Após esse período, o certificado se torna inválido, permitindo a revogação automática de acesso sem intervenção manual. Para casos em que o certificado precisa ser revogado antecipadamente, o OpenSSH suporta listas de revogação de chaves (Key Revocation List - KRL). É possível gerar essa lista no servidor CA com o comando: ssh-keygen -k -f /etc/ssh/ca_revoked_keys. Adicionar o identificador do certificado a ser revogado a uma lista existente pode ser feito com os flags -k e -u: ssh-keygen -k -u -f /etc/ssh/ca_revoked_keys compromised-cert.pub. Aqui, -f especifica o caminho para o arquivo de lista a ser atualizado, e compromised-cert.pub é o certificado ou chave pública a ser revogado. Na prática, no entanto, certificados de curta duração com validade de algumas horas a um dia são mais comumente utilizados. Nesse cenário, os direitos expiram de forma rápida e previsível, reduzindo significativamente a necessidade de usar mecanismos de revogação forçada. Para operação contínua, novos certificados são solicitados periodicamente pelo usuário via API ou através dos sistemas de gerenciamento de acesso mencionados anteriormente. Nesse contexto, o centro de certificação atua como um ponto de controle único, rastreando e registrando cada emissão de chave.
O uso do arquivo authorized_keys continua sendo um mecanismo de autenticação básico. No entanto, em infraestruturas de grande porte, essa abordagem escala mal. A principal dificuldade reside na descentralização. As chaves públicas dos administradores precisam ser armazenadas localmente em cada nó de destino. Como elas não possuem um prazo de validade embutido, o acesso permanece aberto até a exclusão manual. Consequentemente, a atualização ou revogação de direitos se transforma em um processo trabalhoso e multifásico, exigindo a edição do arquivo authorized_keys em todos os servidores. Com esses volumes de trabalho rotineiro, o fator humano é inevitável: erros de digitação, registros duplicados, acessos esquecidos após demissões – tudo isso aumenta exponencialmente o risco de acúmulo de chaves não contabilizadas. Os certificados SSH (CA) representam uma abordagem moderna e escalável. Os certificados podem ter curta duração com expiração automática. Nesse caso, o sistema precisa apenas confiar em um único centro de certificação (CA) e verificar sua assinatura, em vez de armazenar centenas de chaves estáticas. Essa abordagem oferece controle centralizado e flexibilidade, mas requer a implantação de uma infraestrutura CA separada. Sua proteção robusta é crucial: a compromissão do centro permitiria que invasores emitissem certificados falsos em nome de quaisquer usuários. Além disso, a implementação do novo modelo exigirá treinamento da equipe, pois cada funcionário deve ser capaz de obter e revogar seus próprios acessos de forma independente. Como proteger o CA? Aqui está um breve checklist: A chave privada do CA é armazenada em uma máquina protegida e isolada. O acesso à assinatura de certificados é restrito através de autenticação. O registro de todas as operações está ativado. Há separação de funções. A rotação automática de chaves CA está configurada, e backups são criados. A escolha entre authorized_keys e SSH CA depende da escala da infraestrutura. Para um pequeno parque de servidores e um número reduzido de usuários, o esquema tradicional com authorized_keys permanece simples e compreensível. No entanto, à medida que a rede se expande, os custos de manutenção de chaves, auditoria de acessos e revogação de direitos aumentam desproporcionalmente ao número de sistemas. A implantação do SSH CA exige medidas organizacionais adicionais e proteção do centro de certificação. Em contrapartida, essa abordagem oferece gerenciamento centralizado de acesso, suporte a credenciais de curta duração e um nível mais alto de automação.
O desenvolvimento da infraestrutura coloca a empresa diante de uma escolha: utilizar o mecanismo de difícil escalabilidade authorized_keys ou implementar o mais conveniente SSH CA. Com o aumento do número de funcionários, o primeiro caminho inevitavelmente leva ao acúmulo de chaves esquecidas, complica a auditoria e aumenta o risco de erros no gerenciamento de acesso. A segunda abordagem substitui o trabalho com arquivos dispersos por um gerenciamento centralizado através de um único centro de certificação. Isso garante um ciclo de vida controlado das contas e permite a revogação oportuna dos direitos concedidos.
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
Em infraestruturas com centenas ou milhares de servidores e um número considerável de administradores, a contagem de chaves SSH ativas pode facilmente chegar a dezenas de milhares. Por padrão, essas chaves não possuem prazo de validade, o que leva ao acúmulo e obsolescência ao longo do tempo. Estudos indicam que em grandes empresas, até 90% das chaves podem estar em desuso e sem gerenciamento, enquanto uma parte das chaves ativas concede acesso no nível root. A ausência de um gerenciamento centralizado agrava o problema: ao demitir um funcionário, seus acessos podem ser esquecidos, permitindo que ele continue a se conectar aos sistemas. Consequentemente, os administradores se deparam com a tarefa árdua de controlar e atualizar as credenciais de autorização.
Inicialmente, vamos analisar um dos métodos de autenticação mais comuns: a autenticação por chave pública (Public Key Authentication - PKA). Ela ganhou popularidade devido à sua simplicidade, alta resistência criptográfica e à ausência da necessidade de transmitir senhas pela rede. Nas sistemas modernos, o pacote OpenSSH é o padrão de implementação. Por padrão, ele autentica o usuário usando a chave pública, que deve residir no arquivo ~/.ssh/authorized_keys no servidor de destino. Cada linha contém uma chave com opções de acesso. Ao tentar uma conexão, o daemon SSH (sshd) compara os dados apresentados pelo cliente com os registros armazenados e, em caso de correspondência, permite o acesso. A principal dificuldade operacional reside no controle. Com um grande número de usuários, adicionar e revogar seus direitos deve ser feito manualmente. A troca de chaves exige a edição do arquivo authorized_keys em cada máquina – um processo extremamente trabalhoso e propenso a erros humanos. O parâmetro expiry-time pode simplificar um pouco a tarefa, permitindo limitar o tempo de vida da chave. Para definir uma data exata de desativação, utiliza-se a seguinte sintaxe: expiry-time="20261231" ssh-ed25519 AAAAZenZeN0ttIIN1NTENAAAAI… geralt@pc. No entanto, isso não resolve o problema de sincronização e gerenciamento. A proibição completa de acesso geralmente se resume à exclusão física da linha desejada do arquivo authorized_keys em todos os servidores. Para economizar tempo no gerenciamento de chaves no OpenSSH, existe o mecanismo AuthorizedKeysCommand. Este parâmetro do arquivo de configuração sshd_config especifica um comando que retorna dinamicamente a lista de chaves permitidas em vez de ler um arquivo estático. O servidor solicita informações de uma fonte externa – mais comumente um banco de dados onde as chaves públicas estão armazenadas. Com essa abordagem, o administrador precisa apenas remover ou bloquear a chave no repositório central, e ela imediatamente deixa de funcionar em todos os nós da infraestrutura.
O desenvolvimento de tecnologias de nuvem impulsionou o surgimento de novas abordagens para o gerenciamento de chaves, como soluções de Gerenciamento de Acesso Privilegiado (Privileged Access Management - PAM) e Acesso com Confiança Zero (Zero Trust Access). Soluções comuns incluem Teleport, Boundary, Delinea ou CyberArk. Elas combinam um repositório centralizado, interface web e ferramentas de auditoria de sessão. Esses sistemas permitem o abandono de chaves SSH permanentes. Em vez de sua distribuição manual, ao usuário é emitido automaticamente um certificado de sessão de curta duração após a autenticação via SSO (Single Sign-On). Como resultado, os administradores obtêm um portal de gerenciamento unificado e podem revogar direitos de acesso a qualquer momento através da revogação da certificação. A aplicação da combinação de PAM e SSO simplifica significativamente o gerenciamento em larga escala, mas exige uma integração robusta com a infraestrutura existente. A Infraestrutura de Chave Pública (Public Key Infrastructure - PKI) é um sistema de gerenciamento de certificados digitais que garante a autenticidade dos participantes com base na confiança em um único centro de certificação. No SSH, esse modelo é adaptado pela assinatura de identificadores de usuários e hosts por um Centro de Certificação confiável. Uma nova abordagem surgiu devido às dificuldades de escalabilidade: o SSH CA (Certificate Authority) permite substituir o armazenamento de milhares de chaves nos servidores por uma opção mais conveniente – controle centralizado e revogação de direitos após o vencimento. No OpenSSH, um certificado é uma chave pública assinada pela chave privada do CA e equipada com metadados – uma lista de nomes de usuários ou hosts permitidos. No lado do servidor ou cliente, a confiança nas chaves públicas do CA é configurada. A verificação de hosts é realizada da seguinte forma: a chave pública do CA é inserida no arquivo known_hosts com o marcador @cert-authority ou através do arquivo ssh_config. O OpenSSH suporta dois tipos de certificados: de usuário e de host. O primeiro autentica o usuário no servidor, especificando os logins permitidos. Ao usar o segundo, o servidor apresenta o certificado de host ao cliente para confirmar sua autenticidade e garantir a proteção da conexão contra interceptação. A ideia principal em ambos os casos é que o servidor e o cliente confiam não em uma lista de chaves específicas, mas na chave do CA e na assinatura do certificado. Ao se conectar, eles trocam certificados e verificam se a assinatura foi feita por um CA confiável e se o próprio documento ainda não expirou. A principal vantagem dos certificados reside no controle centralizado e na limitação do tempo de vida. Os metadados podem definir explicitamente o período de validade, tornando a chave automaticamente temporária.
Para a implantação de um centro de certificação próprio, é necessário gerar um par de chaves CA – para assinar certificados de usuário e de host: ssh-keygen -t ed25519 -f ~/.ssh/ca_user. O flag -t especifica o tipo de algoritmo de criptografia, e -f define o caminho do arquivo e seu nome. A chave privada ca_user permanece no servidor de automação (ou na máquina do administrador), e a chave pública ca_user.pub é copiada para os servidores de destino no diretório /etc/ssh/ca_user.pub. Em seguida, no arquivo de configuração do servidor /etc/ssh/sshd_config, a diretiva TrustedUserCAKeys /etc/ssh/ca_user.pub é configurada. Após isso, o servidor começará a confiar em todas as chaves assinadas por este centro de certificação. Para que as alterações entrem em vigor, é necessário reiniciar o serviço SSH: sudo systemctl restart ssh. A concessão de acesso ocorre quando o usuário fornece sua chave pública, que é assinada pela chave privada do CA: ssh-keygen -s ca_key -I root -n root id_ed25519.pub. O flag -s indica o caminho para a chave CA, -I define um identificador interno para o certificado (Key ID para logging), e -n especifica a lista de contas permitidas (logins do sistema). Como resultado, é criado o arquivo de certificado id_ed25519-cert.pub. O usuário precisa apenas colocá-lo no mesmo diretório de sua chave privada – o OpenSSH o detectará e aplicará automaticamente durante a conexão. Após configurar a confiança no CA, a administração se resume exclusivamente à emissão e revogação de certificados, eliminando a necessidade de distribuir manualmente as chaves dos usuários pelos servidores. O uso de criptografia robusta também permite o abandono completo de senhas, o que aumenta significativamente o nível geral de segurança da infraestrutura. Os certificados possuem um ciclo de vida estritamente limitado. Ao criá-los através da utilidade ssh-keygen, é possível definir o período de validade usando o flag -V [início_validade]:[fim_validade]. Após esse período, o certificado se torna inválido, permitindo a revogação automática de acesso sem intervenção manual. Para casos em que o certificado precisa ser revogado antecipadamente, o OpenSSH suporta listas de revogação de chaves (Key Revocation List - KRL). É possível gerar essa lista no servidor CA com o comando: ssh-keygen -k -f /etc/ssh/ca_revoked_keys. Adicionar o identificador do certificado a ser revogado a uma lista existente pode ser feito com os flags -k e -u: ssh-keygen -k -u -f /etc/ssh/ca_revoked_keys compromised-cert.pub. Aqui, -f especifica o caminho para o arquivo de lista a ser atualizado, e compromised-cert.pub é o certificado ou chave pública a ser revogado. Na prática, no entanto, certificados de curta duração com validade de algumas horas a um dia são mais comumente utilizados. Nesse cenário, os direitos expiram de forma rápida e previsível, reduzindo significativamente a necessidade de usar mecanismos de revogação forçada. Para operação contínua, novos certificados são solicitados periodicamente pelo usuário via API ou através dos sistemas de gerenciamento de acesso mencionados anteriormente. Nesse contexto, o centro de certificação atua como um ponto de controle único, rastreando e registrando cada emissão de chave.
O uso do arquivo authorized_keys continua sendo um mecanismo de autenticação básico. No entanto, em infraestruturas de grande porte, essa abordagem escala mal. A principal dificuldade reside na descentralização. As chaves públicas dos administradores precisam ser armazenadas localmente em cada nó de destino. Como elas não possuem um prazo de validade embutido, o acesso permanece aberto até a exclusão manual. Consequentemente, a atualização ou revogação de direitos se transforma em um processo trabalhoso e multifásico, exigindo a edição do arquivo authorized_keys em todos os servidores. Com esses volumes de trabalho rotineiro, o fator humano é inevitável: erros de digitação, registros duplicados, acessos esquecidos após demissões – tudo isso aumenta exponencialmente o risco de acúmulo de chaves não contabilizadas. Os certificados SSH (CA) representam uma abordagem moderna e escalável. Os certificados podem ter curta duração com expiração automática. Nesse caso, o sistema precisa apenas confiar em um único centro de certificação (CA) e verificar sua assinatura, em vez de armazenar centenas de chaves estáticas. Essa abordagem oferece controle centralizado e flexibilidade, mas requer a implantação de uma infraestrutura CA separada. Sua proteção robusta é crucial: a compromissão do centro permitiria que invasores emitissem certificados falsos em nome de quaisquer usuários. Além disso, a implementação do novo modelo exigirá treinamento da equipe, pois cada funcionário deve ser capaz de obter e revogar seus próprios acessos de forma independente. Como proteger o CA? Aqui está um breve checklist: A chave privada do CA é armazenada em uma máquina protegida e isolada. O acesso à assinatura de certificados é restrito através de autenticação. O registro de todas as operações está ativado. Há separação de funções. A rotação automática de chaves CA está configurada, e backups são criados. A escolha entre authorized_keys e SSH CA depende da escala da infraestrutura. Para um pequeno parque de servidores e um número reduzido de usuários, o esquema tradicional com authorized_keys permanece simples e compreensível. No entanto, à medida que a rede se expande, os custos de manutenção de chaves, auditoria de acessos e revogação de direitos aumentam desproporcionalmente ao número de sistemas. A implantação do SSH CA exige medidas organizacionais adicionais e proteção do centro de certificação. Em contrapartida, essa abordagem oferece gerenciamento centralizado de acesso, suporte a credenciais de curta duração e um nível mais alto de automação.
O desenvolvimento da infraestrutura coloca a empresa diante de uma escolha: utilizar o mecanismo de difícil escalabilidade authorized_keys ou implementar o mais conveniente SSH CA. Com o aumento do número de funcionários, o primeiro caminho inevitavelmente leva ao acúmulo de chaves esquecidas, complica a auditoria e aumenta o risco de erros no gerenciamento de acesso. A segunda abordagem substitui o trabalho com arquivos dispersos por um gerenciamento centralizado através de um único centro de certificação. Isso garante um ciclo de vida controlado das contas e permite a revogação oportuna dos direitos concedidos.
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.
