A autenticação por chaves assimétricas no SSH baseia-se na distribuição manual de chaves públicas para autenticação. Embora eficaz, este método apresenta limitações quando aplicado em ambientes de larga escala ou com necessidade de gestão centralizada. Os certificados SSH oferecem uma solução mais flexível e controlada, permitindo validar a identidade de utilizadores ou hosts sem depender exclusivamente da troca manual de chaves públicas.

> conceito

No modelo com certificados, existe uma entidade de confiança, denominada Certificate Authority (CA), responsável por assinar as chaves públicas. O processo envolve:

  1. Cada utilizador ou host gera o seu par de chaves (privada/pública).
  2. A chave pública é assinada pela CA, resultando num certificado SSH.
  3. Os servidores ou clientes apenas precisam de confiar na chave pública da CA.

Este modelo simplifica a gestão:

  • É possível renovar certificados de forma centralizada.
  • Reduz a necessidade de manter listas extensas de chaves públicas.
  • Permite definir tempos de validade e restrições nos certificados.

> criar_CA

Gerar par de chaves para CA:

ssh-keygen -f ~/.ssh/ssh_ca \
           -C "CA SSH" \
           -N "passphrase"

Parâmetros utilizados:

  • -f: Define o caminho e nome dos ficheiros das chaves.
  • -C: Comentário identificador para a chave pública.
  • -N: Passphrase para proteger a chave privada.

> assinar_chave

O ssh-keygen suporta dois tipos principais de certificados SSH: certificados de utilizador, usados para autenticar utilizadores nos servidores SSH, e certificados de host, utilizados para autenticar servidores junto dos clientes SSH.

Por omissão, os certificados gerados são válidos para todos os utilizadores ou hosts. Para gerar um certificado válido apenas para determinados principais, deve ser utilizado o parâmetro -n com a lista desejada.

Exemplo para certificado de utilizador:

ssh-keygen -s ~/.ssh/ssh_ca \
           -I "user-cert" \
           -n utilizador \
           -V +4w \
           ~/.ssh/id_ed25519.pub

Exemplo para certificado de host:

ssh-keygen -h \
           -s ~/.ssh/ssh_ca \
           -I "host-cert" \
           -n servidor.exemplo.com \
           -V +52w \
           /etc/ssh/ssh_host_rsa_key.pub

Parâmetros principais:

  • -s: chave privada da CA.
  • -I: identificador do certificado.
  • -n: nome do utilizador/host.
  • -V: validade (exemplo: 4 e 52 semanas).

O certificado gerado será id_ed25519-cert.pub ou ssh_host_rsa_key-cert.pub, respetivamente.

> restricoes

Os certificados SSH permitem a imposição de restrições detalhadas, adaptadas a diferentes necessidades operacionais ou de segurança. Estas restrições controlam o comportamento do utilizador ou do host após a autenticação e delimitam precisamente o tipo de utilização permitido.

Durante o processo de assinatura, o administrador pode definir comandos fixos, limitar acessos por IP, desativar funcionalidades como o encaminhamento, e estabelecer o tipo de certificado. Este nível de controlo garante que mesmo que uma chave seja comprometida, o seu uso indevido é minimizado.

Restrição de comando:

ssh-keygen -s ~/.ssh/ssh_ca \
           -I "user-cert" \
           -n utilizador \
           -V +4w \
           -O force-command="/usr/bin/comando" \
           ~/.ssh/id_ed25519.pub

Força a execução de um comando específico em vez de qualquer comando ou shell fornecido pelo utilizador no momento da autenticação.

Limitação por endereço IP:

-O source-address="192.168.1.0/24"

Limita o acesso apenas a conexões provenientes de endereços IP ou redes específicos.

Desativar o forwarding:

-O no-agent-forwarding -O no-port-forwarding -O no-X11-forwarding

Desativa funcionalidades adicionais durante a sessão SSH, como encaminhamento de agentes, encaminhamento de portos e encaminhamento X11, mitigando riscos associados ao abuso destas funcionalidades.

> configurar_SSHd

Guarde a chave pública da CA num ficheiro, por exemplo: /etc/ssh/ca_key.pub No servidor, adicione a seguinte linha ao ficheiro /etc/ssh/sshd_config:

TrustedUserCAKeys /etc/ssh/ca_key.pub

Reinicie o serviço SSH para aplicar as alterações:

sudo systemctl restart sshd

> revogacao

Para além de configurar a confiança na CA, é recomendável configurar também uma lista de revogação. Em OpenSSH, esta função é suportada através de uma Key Revocation List (KRL), que permite impedir a utilização de certificados ou chaves que deixaram de ser considerados válidos.

Crie uma KRL com o certificado a revogar:

ssh-keygen -k \
           -f revoked.krl \
           certificado-revogado.pub

Para adicionar mais certificados a uma KRL já existente, utilize a opção -u. Esta opção atualiza a lista existente, em vez de criar uma nova KRL do zero.

ssh-keygen -k \
           -u \
           -f revoked.krl \
           outro-certificado.pub

Também é possível adicionar vários certificados na mesma operação:

ssh-keygen -k \
           -u \
           -f revoked.krl \
           outro-certificado.pub \
           mais-um-certificado.pub

Depois de atualizar a KRL, copie novamente o ficheiro revoked.krl para todos os servidores que utilizam a diretiva RevokedKeys.

Copie a KRL para o servidor:

sudo cp revoked.krl /etc/ssh/revoked.krl

No servidor, adicione a seguinte linha ao ficheiro /etc/ssh/sshd_config:

RevokedKeys /etc/ssh/revoked.krl

Reinicie o serviço SSH para aplicar as alterações:

sudo systemctl restart sshd

A partir desse momento, qualquer chave ou certificado incluído na KRL deixa de ser aceite pelo servidor.

> utilizar_certificado

No cliente SSH, especificar o certificado com a opção:

ssh -i ~/.ssh/id_ed25519 \
    -o CertificateFile=~/.ssh/id_ed25519-cert.pub \
    utilizador@servidor

Parâmetros utilizados:

  • -i: Define a chave privada a ser usada na autenticação.
  • -o CertificateFile=: Especifica explicitamente o certificado SSH associado à chave privada.

Caso o certificado esteja corretamente configurado e assinado pela CA confiada pelo servidor, a autenticação será permitida.

> conclusão

A utilização de certificados SSH representa uma evolução significativa face ao modelo tradicional baseado em chaves públicas distribuídas manualmente. Ao introduzir uma entidade central de confiança (CA), é possível simplificar a gestão de credenciais, reduzir a necessidade de manter listas extensas de chaves públicas e aplicar controlos mais rigorosos através de prazos de validade, principais autorizados e restrições específicas.

Esta abordagem é especialmente adequada a ambientes de larga escala, com múltiplos utilizadores e sistemas, permitindo uma gestão mais consistente das políticas de autenticação e reduzindo o risco associado à utilização indevida de chaves antigas, dispersas ou difíceis de controlar.

No entanto, esta centralização também introduz riscos próprios. A chave privada da CA passa a ser um ativo crítico e deve ser protegida com particular rigor, preferencialmente fora dos sistemas de utilização corrente. Uma CA comprometida pode permitir a emissão de certificados válidos para utilizadores ou hosts não autorizados.

A revogação através de KRL permite bloquear certificados ou chaves que deixem de ser confiáveis, mas a sua eficácia depende da atualização e distribuição dessas listas por todos os sistemas relevantes. Por esse motivo, os certificados SSH devem continuar a ser emitidos com prazos de validade curtos, reduzindo a janela de exposição em caso de compromisso, erro de emissão ou alteração de permissões.

Os certificados SSH reduzem a complexidade da gestão de acessos, mas não substituem processos disciplinados. A sua eficácia depende tanto da configuração técnica como da qualidade dos procedimentos de emissão, proteção da CA, renovação, revogação e auditoria.

> status: signed
> exit 0