É um local central para authorized_keys uma boa ideia?

26

Estou no processo de configurar um servidor de nuvem para executar a seguinte pilha: Ruby, Passenger, Apache; no Ubuntu 10.04 (Lucid Lynx).

No processo de facilitar o gerenciamento do servidor, eu configuro as chaves RSA em root e www-data para que eu possa ssh no servidor. O que eu não gostei foi que o diretório www-data .ssh estava em /var/www , que é a configuração do diretório padrão do apache. Minha preocupação é que, se o apache não estiver configurado corretamente, o diretório .ssh poderá ser exposto.

Me deparei com a solução para mover o arquivo ~/.ssh/authorized_keys para um local central alterando AuthorizedKeysFile em /etc/ssh/sshd_config . Isto vem com 2 prós: um único local para chaves, e não ter que se preocupar com uma configuração ruim do apache. O con único que eu posso pensar é que agora todo usuário está disponível para login no servidor (claramente uma espada de dois gumes do arquivo de chave central.)

Existe alguma coisa que eu perdi nessa configuração? Eu já me expus, ou esta é uma solução melhor do que os arquivos authorized_keys individuais?

Sou verde quando se trata de gerenciamento de servidores, mas estou totalmente pronto para ser chamado de nomes ruins para fazer coisas ruins. : D

    
por Gavin Miller 20.09.2011 / 15:05

2 respostas

49

Todos os arquivos de chaves podem ser centralizados no mesmo diretório e não misturados no mesmo arquivo.

Basta configurar o arquivo sshd_config da seguinte forma:

AuthorizedKeysFile  /etc/ssh/authorized_keys/%u

No seu servidor:

  • as chaves www-data estarão em /etc/ssh/authorized_keys/www-data
  • As chaves raiz
  • estarão em /etc/ssh/authorized_keys/root

Em relação aos direitos de acesso, essas configurações são aceitas pelo sshd:

/etc/ssh/authorized_keys é de propriedade de root:root e possui o modo 755. Os arquivos-chave são de propriedade de root:root e possuem o modo 644.

Outros modos podem funcionar, mas eu não os testei.

    
por 05.09.2012 / 18:05
15

Em geral, eu não faria o que você está sugerindo. Ele quebra suposições comuns (como ~/.ssh/authorized_keys trabalhando para seus usuários e apresenta problemas que você já mencionou em sua pergunta. Se você vir problemas evidentes antes da implementação, significa que sua solução não é ideal.

Em termos de segurança, também acho que é uma ideia TERRIBLE para que todos compartilhem uma conta de serviço: no momento, é só você e você sabe que é quem está fazendo alterar. Em 5 anos, quando você tem 5 administradores, você vai querer saber quem mudou o quê, e vasculhar os registros de auditoria para ver quem usou a chave quando é uma dor real. É melhor que as pessoas façam login como elas mesmas e usem sudo ou algo similar para aumentar seus privilégios e fazer o que for necessário.

Se você ainda quiser centralizar as chaves SSH, sugiro pesquisar em um sistema de implantação como Puppet ou radmind para gerenciar / distribuir os arquivos authorized_keys para os diretórios ~user/.ssh/ apropriados (ou criar uma solução caseira que os SCPs implementem).
À medida que você expande para vários servidores, convém olhar para o patch de chave pública do LDAP para versões mais antigas do OpenSSH (ou a AuthorizedKeysCommand diretiva e um script apropriado em uma versão mais nova do OpenSSH) para que você possa centralizar seus usuários e não precisar distribuir suas chaves por toda a rede, mas é provável que isso esteja bem abaixo do esperado.

    
por 20.09.2011 / 15:41