Início / unix / Perguntas / 550599
Accepted
iBug
Asked: 2019-11-06 21:26:02 +0800 CST

SSH User CA: Assinar um certificado de usuário com hosts selecionados em vez de todos os hosts?

  • 772

Eu tenho muitos servidores que compartilham um arquivo TrustedUserCAKeys. Eu quero assinar um certificado de usuário para que ele conceda algum acesso a servidores específicos em vez de todos eles.

Por exemplo, o comando a seguir gera um certificado que pode ser usado para efetuar login como root em todos os servidores:

ssh-keygen -s ca -I example -n root id_rsa.pub

Eu tentei o seguinte comando, mas ele gera um certificado que é... inútil.

ssh-keygen -s ca -I example -n root@server1 id_rsa.pub

Eu pretendia gerar um certificado que só pode entrar como root no servidor1, mas não como root em nenhum outro servidor. Certifiquei-me de que server1é o FQDN nesse servidor (ou o conteúdo completo de /etc/hostname). Existe uma maneira de conseguir isso sem tocar sshd_configem nenhum host?

ssh

2 respostas

  1. Best Answer

    Sem alterar o sshd_configarquivo, a resposta geralmente é não. O mecanismo para fazer isso é configurar um AuthorizedPrincipalsFile(ou AuthorizedPrincipalsCommand). Sem essa diretiva em sshd_config, o comportamento padrão é que o nome de usuário para a tentativa de autenticação deve ser listado literalmente como um dos principais incorporados no certificado. É por isso que 'root' funciona, mas 'root@server1' não.

    Para fazer um certificado usando 'root@server1' funcionar (sem adicionar entradas em /root/.ssh/authorized_keys), você precisaria configurar um AuthorizedPrincipalsFilepara o usuário root (versões posteriores do OpenSSH permitem esta diretiva dentro de um Matchbloco) e listar 'root@server1', e faça algo semelhante em outros servidores. Você também pode estender isso para permitir certificados aplicáveis ​​a grupos de servidores, como 'root@dev' ou mesmo 'root@*', desde que cada tipo apropriado esteja listado como principal no arquivo AuthorizedPrincipalsFile.

    Outra maneira de implementar isso é listar explicitamente a chave da CA e os principais permitidos no .ssh/authorized_keysarquivo, usando as opções cert-authoritye principals= . Eles são abordados na sshddescrição da página do manual do Formato de arquivo Authorized_Keys.

    • 2

  2. O problema é que quando você emite o certificado ssh, se você o colocar diretamente root , Principalsestará dando acesso a todos os servidores que confiam em sua CA.

    Para evitar isso, nunca emita um certificado com username. Em vez disso, crie uma estratégia de acesso. Um cenário típico é que algumas pessoas precisam acessar servidores de teste, algumas precisam acessar servidores de banco de dados e algumas precisam acessar todos os servidores. Então eu crio vários princípios

    • project-dev - Acesso a Servidores de Desenvolvimento/Teste
    • project-databases- Acesso a servidores de banco de dados
    • project-super- Acesso a todos os servidores

    Para conseguir isso, adicione AuthorizedPrincipalsFile /etc/ssh/auth_principals/%uno sshd_configarquivo.

    Então, quando alguém tenta fazer login em um servidor com nome de rootusuário, ele verifica o arquivo /etc/ssh/auth_principals/root(aviso %usignifica usuário).

    Portanto, se o certificado do usuário tiver um princípio listado neste arquivo, o usuário terá acesso.

    O arquivo de princípios autorizados para este cenário será

    • Servidores de desenvolvimento -project-dev\nproject-super
    • Servidores de banco de dados -project-dev\nproject-super
    • Servidores de Produção -project-super

    Portanto, crie uma estratégia de acordo com suas necessidades.

    Nota: Se você ainda emitir o certificado com rootele Principlesainda funcionaria. Então evite isso.

    Eu escrevi um blog para configurar a infraestrutura completa do certificado ssh:

    https://medium.com/better-programming/how-to-use-ssh-certificates-for-scalable-secure-and-more-transparent-server-access-720a87af6617

    • 1

relate perguntas