Certificados SSH: uma experiência SSH melhor

 (jpmens.net)
6 pontos por GN⁺ 27 일 전 | 1 comentários | Compartilhar no WhatsApp
  • Os certificados SSH resolvem a complicação da autenticação SSH tradicional baseada em chave pública e fornecem confiança automática entre cliente e servidor
  • Suportados desde o OpenSSH 5.4, permitem que uma CA (autoridade certificadora) assine chaves de usuário e de host, possibilitando autenticação sem editar o authorized_keys
  • Os certificados podem incluir validade, usuários permitidos (principal), IPs de acesso, comando forçado (force-command) etc., oferecendo controle de acesso granular
  • O processo de TOFU (Trust on First Use) é eliminado, e é possível se conectar com segurança sem alertas quando a chave de host muda
  • Com um servidor de assinatura automática ou ferramentas auxiliares, é possível automatizar a gestão de SSH em ambientes com muitos servidores e melhorar a segurança

Visão geral dos certificados SSH e limitações da autenticação SSH tradicional baseada em chaves

  • Ao estabelecer uma conexão SSH, é preciso verificar a impressão digital (fingerprint) da chave de host de um servidor acessado pela primeira vez, mas a maioria dos usuários não faz essa validação e apenas digita “yes”, usando o modelo TOFU (Trust on First Use)
    • Administradores podem verificar a impressão digital diretamente no servidor ou com o comando ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key
  • A autenticação baseada em chave pública permite acesso sem senha, mas exige distribuir a chave pública para o arquivo authorized_keys de cada servidor
  • Com o agente SSH (ssh-agent), é possível manter a chave privada na memória e autenticar sem redigitá-la repetidamente
  • Limitações da abordagem tradicional
    • É necessário copiar a chave pública para os servidores de cada usuário
    • Quando a chave de host muda, o cliente exibe uma mensagem de alerta
    • O TOFU torna a gestão de confiança incômoda

Certificados SSH e autoridade certificadora (CA)

  • Os certificados SSH (Certificate) são suportados desde o OpenSSH 5.4 (março de 2010) e estendem o formato tradicional de chave SSH
  • Uma CA SSH é composta por um par de chaves SSH, e a chave pública atua como raiz de confiança
  • Principais vantagens
    • Não é necessário modificar o arquivo authorized_keys do servidor
    • Não há alertas ao trocar chaves de host
    • A remoção do processo TOFU permite implementar confiança automática
    • É possível incluir no certificado usuários permitidos (principal), IPs permitidos, validade, comando forçado (force-command) etc.
    • O acesso é bloqueado automaticamente quando o certificado expira

Configuração de uma SSH CA e processo de assinatura

  • No sistema da CA, gerar um par de chaves da CA com o algoritmo ECDSA
    • ssh-keygen -t ecdsa -C "SSH CA" -f CA/ssh-ca
  • O usuário envia sua chave pública (*.pub) para a CA, e a CA a assina (sign) para emitir um certificado (*-cert.pub)
    • Ex.: ssh-keygen -s CA/ssh-ca -I "Jane Jolie" -n jane -z 001 -V +1w jane.pub
  • Configuração do servidor
    • Salvar a chave pública da CA em /etc/ssh/ssh-ca.pub e adicionar a configuração TrustedUserCAKeys
    • Assinar a chave de host do servidor com a CA (ssh-keygen -h -s CA/ssh-ca ...) e registrá-la em HostCertificate
  • Configuração do cliente
    • Adicionar uma linha @cert-authority ao arquivo known_hosts
    • Ex.: @cert-authority *.example.com $(cat CA/ssh-ca.pub)

Conexão e validação com base em certificados SSH

  • O usuário se conecta usando o certificado assinado junto com a chave privada (ssh -i jane -l jane alice.example.com)
  • Os logs do servidor registram o ID, número de série (serial) e fingerprint da CA do certificado
  • É possível adicionar vários nomes de host ou IPs como principal no certificado
  • Ao tentar fazer login com um usuário diferente do principal definido no certificado, ocorre o erro “Certificate invalid: name is not a listed principal”
  • É possível aplicar controle de acesso detalhado com comando forçado (force-command) ou IP permitido (source-address) no certificado

Checklist de verificação e solução de problemas

  • Itens a verificar no servidor

    • Configuração de TrustedUserCAKeys e presença da chave pública da CA
    • Assinatura da chave de host e definição de HostCertificate
    • É necessário reiniciar o sshd

  • Itens a verificar no cliente

    • A chave do usuário deve estar assinada pela CA
    • A entrada @cert-authority em known_hosts e o principal precisam corresponder
    • Quando o certificado expira, aparece a mensagem “Certificate invalid: expired”
    • Quando as restrições do certificado não coincidem, pode haver solicitação de senha
    • Ao adicionar o certificado ao agente SSH, tanto a chave quanto o certificado são registrados (ssh-add jane)
    • É possível controlar funcionalidades com opções (-O) no momento da assinatura
    • Ex.: com -O clear, remove-se toda permissão e permite-se apenas permit-agent-forwarding e permit-port-forwarding

Automação de certificados de chave de host

  • É possível implementar um servidor de assinatura automática (hkbot) com o módulo Python sshkey-tools e BottlePy
    • Executar hkbot.py no servidor da CA e assinar automaticamente a chave pública do host quando ela for enviada por requisição HTTP
    • No cliente, instalar automaticamente com o comando curl -F hostkey=@/etc/ssh/ssh_host_ed25519_key.pub http://CA:8870 | sh
    • Aplicar após modificar e validar /etc/ssh/sshd_config com systemctl restart sshd
  • Depois disso, nas conexões SSH, a confiança automática e o login passam a funcionar com base em certificados

Resumo das vantagens dos certificados SSH

  • TOFU desnecessário, com confiança automática entre cliente e servidor
  • Emissão de certificados de curta validade para controle de acesso temporário
  • Bloqueio automático de acesso ao expirar o certificado, sem necessidade de limpar authorized_keys
  • Configuração de políticas detalhadas, como comando forçado, restrição de PTY e controle de IP de acesso
  • Ferramentas de automação permitem simplificar a gestão de ambientes com muitos servidores
  • O projeto relacionado Smallstep SSH é apresentado

Materiais adicionais de referência

Atualização

  • Uma SSH CA é especialmente útil em ambientes com servidores próprios e acesso root
  • Em sistemas com múltiplos usuários, os métodos tradicionais com known_hosts e authorized_keys ainda continuam necessários
  • Rascunho de padronização do formato de certificado SSH: draft-miller-ssh-cert-06

Leituras relacionadas

1 comentários

 
GN⁺ 27 일 전
Comentários no Hacker News

  • É surpreendente que as pessoas ainda usem senha de SSH
    Especialmente em ambientes de grandes empresas, várias políticas de senha se misturam, então até acessar um servidor pode levar bastante tempo
    Por isso, mesmo que você diga para usarem chaves com ssh-keygen, a maioria pensa “qualquer dia eu faço” e acaba nunca fazendo

    • As chaves são úteis quando há um sistema central de gerenciamento na empresa ou para uso pessoal
      Mas, na prática, é fácil a gestão virar uma bagunça, como usar uma mesma chave pública em vários servidores ou compartilhar chaves
      Pelo menos as senhas têm a vantagem de serem simples
    • Há anos eu gerencio minhas chaves SSH com um HSM baseado em Yubikey
      Não há senha, mas no login é preciso tocar fisicamente na Yubikey
    • O uso distribuído de chaves com algo como ssh-copy-id facilita o movimento lateral de hackers dentro da rede, então muitas organizações bloqueiam isso

  • A cada poucos meses alguém redescobre os certificados SSH e escreve um post no blog
    Eu também escrevi um post relacionado há 15 anos, mas olhando agora ele era incompleto

    • Muita gente confunde chaves e certificados
      Até engenheiros de segurança às vezes esquecem que estão usando autenticação por chave, e não certificados SSH
    • Certificados SSH são úteis porque permitem conceder acesso a um usuário específico com período de validade e permissões limitados
    • Eu também já conhecia certificados SSH, mas não consegui sair do modelo baseado em chaves
      Gerenciar manualmente as chaves de vários servidores é trabalhoso demais
      Ainda estou pensando se vale a pena migrar agora
    • Quando meu trabalho criou uma CA de SSH há 10 anos, usamos esse post de blog como referência

  • O modelo TOFU (Trust On First Use) é simples, mas vai razoavelmente longe
    Nos meus servidores, depois de verificar diretamente a chave do host, isso já basta
    Em ambientes corporativos grandes, dá para publicar a lista de chaves públicas dos servidores internos em um site interno assinado por SSL
    Mas em ambientes com muitos servidores ou mudanças frequentes, certificados são muito melhores, e o TOFU tem limitações em vários aspectos
    Também seria bom se os navegadores avisassem quando a chave TLS de um servidor mudasse

    • Uso SSH desde 1996, mas nunca vi ninguém realmente verificar manualmente a chave pública
      A maioria só digita “yes” e segue em frente

  • Na empresa, desperdiçamos muito tempo e dinheiro por causa da inspeção SSL da Zscaler
    Quando aparece o erro “self-signed certificate in certificate chain”, sempre vira dor de cabeça

    • Analisei o Zscaler instalado no Windows 11 de um amigo, e era quase nível malware
      Ele injeta seu próprio certificado raiz e bloqueia as configurações do navegador para impedir o uso de proxy
      Mesmo que você altere os arquivos de configuração do Firefox ou do Chrome, ele sobrescreve tudo imediatamente
      Para desativar pela interface gráfica, é preciso a senha da TI
      É só um pouco melhor que o antivírus da Cybereason
    • O Cisco Umbrella da nossa empresa é a mesma coisa
      Ele quebra todos os protocolos baseados em HTTP
      Git, RubyGems, go mod, Nix e muitas outras ferramentas param de funcionar
      O fornecedor diz que é “transparente”, mas na prática não é nem um pouco
      Leva horas para diagnosticar o problema, e a maioria dos administradores nem sabe o poder destrutivo que isso tem
    • Só para constar, certificados SSH não são iguais a certificados X.509

  • O texto menciona apenas as vantagens dos certificados de CA, mas as desvantagens também existem claramente
    Eu nunca tive problemas de segurança por causa de TOFU

    • Dizer “nunca houve incidente, então é seguro” é a mesma lógica de dizer que não precisa usar cinto de segurança
      Se certificados SSH têm desvantagens, eu gostaria de saber exatamente quais são
    • TOFU é conveniente, mas não é obrigatório
      Se quiser reforçar a segurança, você pode trocar a chave pública por um canal seguro, como USB
      Mesmo usando certificados, no fim você precisa seguir o mesmo procedimento; a única diferença é que a responsabilidade da gestão sai do usuário e vai para o administrador
      Em organizações grandes, certificados podem ser úteis, mas a segurança geral é a mesma
    • Se você puder configurar a CA antecipadamente, dá para evitar TOFU
      Basta incluí-la no script de instalação ou na imagem de deploy
      TOFU só faz sentido ao acessar uma máquina já configurada
    • Dizer “ainda não houve incidente de segurança por causa de TOFU” significa apenas que ainda não houve

  • No nosso ambiente dev/stg, reinstalamos metade das máquinas todos os dias
    Graças aos certificados de host SSH, ficou muito mais prático, sem precisar apagar known_hosts nem preservar chaves

  • Estou criando uma ferramenta chamada Sshifu como projeto pessoal
    É uma ferramenta para facilitar login baseado em certificados SSH e SSO
    Você instala o sshifu-server no servidor para usá-lo como CA, e cada servidor SSH é configurado para confiar nessa CA
    Para o usuário, basta fazer login com o comando npx sshifu
    Veja o repositório no GitHub

  • Em ambientes de produção reais, acesso baseado em certificados leva a problemas complexos de administração
    Surgem várias questões, como expiração de certificados, remoção de usuários e login durante falha de servidor
    Na Userify, lidamos com esses problemas há 15 anos, e montar uma infraestrutura estável de autenticação SSH nunca é simples

    • Mesmo assim, acho que o modelo SaaS é a pior escolha possível

  • Adicionei suporte a certificados SSH no pico.sh, e isso foi muito útil porque permitiu implementar controle de acesso no estilo RBAC
    Veja a documentação

  • Em produção, certificados SSH acabam centralizando a complexidade e piorando o problema
    Uma única CA precisa estar sempre disponível, e se ela falhar o acesso inteiro é bloqueado
    Também há muitos problemas práticos, como ajuste de TTL, gerenciamento da raiz de confiança e dificuldade para depurar
    No fim, as pessoas acabam reintroduzindo cache ou agentes
    Nós seguimos o caminho oposto: cada nó sincroniza as informações de usuário por HTTPS para o authorized_keys local
    Assim dá para manter o controle centralizado, mas com falhas localizadas
    A Userify usa esse método, cuidando não só da autenticação como também da gestão de permissões
    Certificados sozinhos não resolvem problemas como criação de usuários, papéis de sudo e limpeza de diretórios home

    • Perguntaram como isso resolve o TOFU