Eu encontrei essa pergunta ao tentar responder sozinho. Depois de algumas pesquisas e experimentações, encontrei algumas outras opções para isso. Eu vou pular a parte sobre distribuição de chaves como alternativa desde que Matt Simmons cobriu isso. Além disso, sei que há momentos em que isso não é bom o bastante. Por exemplo, se você for o GitHub e tiver que armazenar milhões de chaves públicas em um único usuário, a atualização contínua dos arquivos authorized_keys do SSH e mantê-los sincronizados entre potencialmente dezenas de centenas de caixas de borda não é viável ou desejável.
Então,
-
Antes de mais nada, o RedHat (e variantes) tem um patch compatível com o OpenSSH que adiciona as opções
AuthorizedKeysCommand
eAuthorizedKeysCommandRunAs
. O patch foi mesclado upstream no openssh 6.2. Para citar a página de manual :AuthorizedKeysCommand
Specifies a program to be used for lookup of the user's public keys. The program will be invoked with its first argument the name of the user being authorized, and should produce on standard output AuthorizedKeys lines (see AUTHORIZED_KEYS in sshd(8)). By default (or when set to the empty string) there is no AuthorizedKeysCommand run. If the AuthorizedKeysCommand does not successfully authorize the user, authorization falls through to the AuthorizedKeysFile. Note that this option has an effect only with PubkeyAuthentication turned on.
AuthorizedKeysCommandRunAs
Specifies the user under whose account the AuthorizedKeysCommand is run. Empty string (the default value) means the user being authorized is used.
Em meus experimentos de hoje à noite, descobri que fora da caixa, isso não funciona devido às políticas padrão do SELinux. Você pode contornar isso desativando a aplicação do SELinux com
setenforce 0
. Como a conversão do SELinux é provavelmente uma idéia ruim , você pode gerar a política correta. No meu caso, foi tão simples quanto tentar fazer login com a opçãoAuthorizedKeysCommand
configurada em/etc/ssh/sshd_config
e, em seguida, usandoaudit2allow -a -M local && semodule -i local.pp
. Isso basicamente analisa os logs de auditoria e encontra coisas que foram evitadas e gera exceções para elas. Se é provável que você tenha outras coisas que possam ficar na lista de permissões, provavelmente você deve saber mais sobreaudit2allow
para garantir que as novas políticas sejam aplicadas corretamente. -
Existem outros vários patches (provavelmente menos testados e confiáveis) disponíveis para adicionar funcionalidades semelhantes. Por exemplo, existe openssh-script-auth . Você também pode encontrar o patch que o RedHat usou e aplicá-lo diretamente. Uma rápida pesquisa de Googling revela o link e link que são baseados nas versões RH mas que foram atualizadas para versões mais novas do OpenSSH.
-
Patch OpenSSH para realizar pesquisas importantes diretamente de alguma loja (por exemplo, GitHub e CodeBaseHQ e outros fizeram). O GitHub não abriu o código para este patch, pelo que sei, mas sei que no passado encontrei versões para MySQL e PostgreSQL. Eu tentei encontrá-los novamente agora, mas não tive muita sorte.
-
Existem também algumas opções baseadas no FUSE. Por exemplo, há LPKFuse que permite que você atenda chaves públicas do LDAP alterando a localização
AuthorizedKeysFile
para uma no sistema de arquivos LPKFuse . O LPKFuse FS cria arquivos virtuais cujo conteúdo é feito por campos de um servidor de diretório.
Em suma, acho que a opção nº 1 é de longe a melhor, pois é oficialmente suportada pelo RedHat. Além disso, permite colocar qualquer lógica que você goste nesse script (incluindo falar com um banco de dados) em qualquer idioma desejado.