Autenticador do Google / SSH: vários segredos compartilhados por usuário e compartilhamento de segredos compartilhados sobre os usuários

Question

Eu gostaria de adicionar o aplicativo de autenticação do Google à nossa ferramenta toolchain de autenticação SSH, conforme descrito em este artigo

No entanto, parece que o módulo PAM faz basicamente um link entre "usuário linux" e "usuário de autenticação". Isso causa os seguintes 2 problemas para nós:

• Se tivermos vários usuários no sistema (para várias finalidades diferentes), será difícil (impossível?) compartilhar o método de autenticação do google (segredo compartilhado TOTP) entre eles.
• Se várias pessoas reais desejarem efetuar login no mesmo usuário linux, isso nos força a compartilhar o segredo entre os usuários reais.

Na abordagem SSH padrão, em que a chave de qualquer pessoa real pode ser adicionada a qualquer authorized_keys de determinado usuário linux, esses problemas não são aplicáveis. Como faço para criar o equivalente na configuração do Google-pam?

    

Answer 1

As contas compartilhadas não funcionam bem com a autenticação de dois fatores, já que o 2fa geralmente existe para provar que um usuário é quem ele diz ser. Em vez de contas compartilhadas, você deve usar funções ou troca de usuários: alguém se conecta com suas próprias credenciais como conta própria e executa uma operação sudo para se tornar uma conta compartilhada. Isso tem vários benefícios, incluindo recursos de auditoria muito melhores.

Eu não acredito que você possa fazer o PAM funcionar do jeito que você quer, sem criar um segredo compartilhado que você dá a todos os seus usuários - e mesmo assim você terá problemas quando as pessoas ficarão bloqueadas devido à reutilização de tokens (por exemplo userA conecta e usa o token 555555, em seguida, o userB se conecta ao mesmo tempo e tenta usar o mesmo token 555555, que falha porque já foi usado uma vez). Acredito que você pode permitir a reutilização de tokens no google authenticator, mas isso basicamente nega toda a parte "única" de "OTP".

    

Answer 2

Existe uma maneira de distinguir o humano durante o processo de login e, apesar de todos os 5 humanos usarem a mesma conta "raiz".

Claro que o módulo PAM tem seus limites neste momento.

Mas você deve dar uma olhada em privacyIDEA . Este projeto meu permite gerenciar qualquer tipo de tokens (também TOTP, HOTP Google Authenticator, token de hardware, yubikey ...) e atribuir esses tokens aos usuários.

Agora existem duas possibilidades:

A) Você pode atribuir vários tokens para a raiz do usuário. E você sabe qual token foi entregue a qual humano. No servidor, você instala um módulo pam privacyidea, que é autenticado no servidor privacyidea. privacyidea determina qual token foi usado para autenticar como usuário root e registra isso no log de auditoria assinado digitalmente. Assim você pode deduzir, qual humano está logado.

B) Todo ser humano tem sua própria conta de usuário em privacyidea. Você atribui um token a cada conta de usuário e entrega esse token para o humano. Agora você pode atribuir tokens "remotos" ao usuário root. Assim, o usuário root obtém algum tipo de tokens virtuais que se ligam aos tokens reais dos usuários humanos. Quando um usuário "root" autentica, você obtém as informações sobre o token virtual / remoto e o token do usuário do território no log de auditoria. Assim, você vê diretamente qual humano está logado como usuário root.

Contas compartilhadas é uma má ideia

Afirma-se que as contas compartilhadas são uma má ideia. Eu recomendaria esta afirmação. Evite contas compartilhadas! Mas às vezes pode ser muito difícil evitar contas compartilhadas. Então a questão é: qual é a coisa ruim sobre contas compartilhadas? E se pudermos atenuar esse problema de contas compartilhadas, as contas compartilhadas podem não ser mais tão ruins assim.

Eu acho que uma grande coisa ruim sobre contas compartilhadas é que você não pode distinguir qual ser humano está logado e realizou as ações. Então, se você tem a possibilidade de diferenciar qual humano está logado como shared_user_A , então o problema pode não ser tão grande assim. Nesse caso, 2FA é uma boa possibilidade, porque você pode identificar qual fator de segunda posse foi usado para fazer login na conta compartilhada. E se você conseguir igualar o número de série do fator de posse ao humano, então você estará relativamente limpo novamente.

Em seu cenário de SSH, convém combinar chaves ssh (em chaves autorizadas) com o TOTP Google Authenticator compartilhado. Um humano precisa ter ambos, uma chave ssh exclusiva (pela qual você pode identificar o humano) e um TOTP compartilhado.