A autenticação interativa com teclado suporta duas senhas sequenciais?

Question

Autenticação interativa por teclado ( RFC 4256 ), que é implementada como ChallengeResponseAuthentication no arquivo de configuração do OpenSSH, permite um para encadear vários métodos de autenticação. Por exemplo, senha e TOTP. Também é possível encadear várias senhas, ou seja, quando o usuário se conecta a um servidor, ele solicita password1 e, em seguida, password2 ? Ou isso depende apenas dos módulos PAM e da configuração do PAM? A razão pela qual eu pergunto é que tal configuração quebraria a maioria, se não todas as ferramentas automáticas de força bruta SSH, enquanto ainda não requer que o usuário tenha qualquer coisa.

    

Answer 1

A resposta é sim. Você está apontando para o alvo correto, mas falta algumas peças:

Usando ChallengeResponseAuthentication , você pode definir mais métodos de autenticação, mas para garantir que eles sejam solicitados ao usuário, é necessário especificar a lista deles em AuthenticationMethods , por exemplo, como este em sshd_config (fazer pam duas vezes é apenas um exemplo para tentar como funciona):

ChallengeResponseAuthentication yes
AuthenticationMethods keyboard-interactive:pam,keyboard-interactive:pam

Mas, para observar, você pode fazer o mesmo somente no PAM adicionando método adicional em /etc/pam.d/sshd .

Como nota de rodapé, sim. Provavelmente, a maioria das ssh scans normais falham. Mas ataques de força bruta, se forem direcionados, podem adivinhar uma ou duas senhas. Não importa. Mas todos eles ainda vão perder o tempo do seu computador. E você ainda precisa de senhas strongs, se não quiser desabilitá-las (o que deve ser preferido).

    

Answer 2

Teoricamente, é possível, mas usando algo como um servidor Radius para uma das duas autenticações. Caso contrário, deve desenhar um segundo banco de dados para a senha2.

Mas se a intenção é evitar as ferramentas automatizadas de força bruta, acredito que a melhor abordagem é a da segurança através da obscuridade , ou simplesmente mudar a porta padrão do ssh de 22 para, por exemplo, 2233. Para mim, esta solução funcionou e a força bruta dos "ataques" desapareceu completamente ...