Permitir que usuários utilizem ssh para usuários específicos através de ldap e chaves públicas armazenadas

Question

Eu configurei recentemente o gitolite, onde os usuários acessam o repositório git com o usuário "gitolite" através do ssh.

Agora eu gostaria de integrar isso no LDAP. Cada usuário tem pubkey no LDAP e se ele tem "git" objectClass, ele seria capaz de acessar o usuário "gitolite" através do ssh.

Eu sei que é possível armazenar chaves públicas no LDAP, não tenho certeza se é possível permitir autenticação na conta "gitosis" com base em objectClass.

EDITAR: Para esclarecer, com objectClass git, o usuário "foobar" poderá fazer o login como "gitolite" através de ssh

    

Answer 1

O autor de gitolite adicionou alguns recursos que ajudam a suportar armazenamentos de chaves externas e informações de associação a grupos. Pesquise o CHANGELOG para o LDAP.

Para usar um armazenamento de chave externa, seu sshd precisa suportar o usual arquivo .ssh/authorized_keys (este é o arquivo que diz a sshd para executar gl-auth-command quando um gitolite usuário efetua login ).

1. Desative a geração de authkey normal (aquela baseada no keydir no repositório gitolite-admin ):% $GL_NO_SETUP_AUTHKEYS = 0; em seu .gitolite.rc .
2. Periodicamente (sempre que uma chave é alterada, um usuário é adicionado, etc.):
   1. Extraia todas as chaves SSH de seu armazenamento de chaves em algum diretório conveniente e temporário (use os mesmos nomes para os arquivos de chaves, como se estivessem no keydir do repositório normal).
   2. Execute gl-setup-authkeys para que gitolite reconstrua sua parte do arquivo authorized_keys .

Veja a mensagem de submissão que introduziu gl-setup-authkeys para o autor própria descrição.

Usar grupos de usuários definidos externamente é um pouco mais complicado, pois geralmente envolve a interposição de outro programa entre sshd e gl-auth-command (as associações a grupos são passadas como argumentos extras para gl-auth-command ). Consulte “grupos de usuários e LDAP / ferramentas semelhantes” .

    

Answer 2

Se você quiser tentar algo um pouco fora do alcance, faça com que o .ssh / authorized_keys2 seja um pipe nomeado e escreva um script / programa que consulte o LDAP, execute a filtragem adequada e, em seguida, expulse o conteúdo de uma chave authorized_keys . Eu sugiro o authorized_keys2 já que você provavelmente já está usando authorized_keys.

Você teria que ter cuidado com o script (observar o bloqueio de gravações, saber quando fazer uma nova consulta, etc.), mas ele forneceria a resposta certa toda vez se você fizesse isso corretamente.