pam service (sshd) ignorando tentativas máximas

28

Eu tenho vps que eu uso para executar um servidor web, atualmente ele roda o servidor Ubuntu 12.04. Desde algumas semanas recebo muitos erros no meu console ssh.

2014 Apr 11 08:41:18 vps847 PAM service(sshd) ignoring max retries; 6 > 3
2014 Apr 11 08:41:21 vps847 PAM service(sshd) ignoring max retries; 6 > 3
2014 Apr 11 08:41:24 vps847 PAM service(sshd) ignoring max retries; 6 > 3
2014 Apr 11 08:41:25 vps847 PAM service(sshd) ignoring max retries; 6 > 3
2014 Apr 11 08:41:26 vps847 PAM service(sshd) ignoring max retries; 6 > 3
2014 Apr 11 08:41:29 vps847 PAM service(sshd) ignoring max retries; 6 > 3
2014 Apr 11 08:41:29 vps847 PAM service(sshd) ignoring max retries; 6 > 3

Alguém poderia me dizer o que esses erros significam? Ou pelo menos me diga como desabilitar esses erros. É realmente irritante quando estou trabalhando sobre o ssh e esses erros continuam aparecendo em toda a minha tela.

    
por Jerodev 11.04.2014 / 08:43

6 respostas

36

PAM está lhe dizendo que está configurado com "retry = 3" e irá ignorar quaisquer outras solicitações de autenticação do sshd dentro da mesma sessão. No entanto, SSH continuará tentando até esgotar a configuração MaxAuthTries (cujo padrão é 6).

Você provavelmente deve definir ambos (SSH e PAM) para o mesmo valor para o máximo de tentativas de autenticação.

Atualizado

Para alterar este comportamento:

Para sshd , edite /etc/ssh/sshd_config e defina MaxAuthTries 3 . Também reinicie o servidor SSH para que a configuração entre em vigor.

Para PAM , você precisa procurar a configuração no diretório /etc/pam.d (acho que é common-password no Ubuntu), você precisa alterar o valor retry= .

Nota: Eu sugeriria strongmente que eu também checasse a resposta de Peter Hommel sobre o motivo destes pedidos, já que é possível que seu SSH esteja sendo forçado a brutalidade.

    
por 11.04.2014 / 10:03
37

Enquanto as outras respostas estão corretas para elimi- nar a mensagem de erro, considere que essa mensagem de erro pode ser apenas um sintoma de outro problema subjacente.

Você recebe essas mensagens porque há muitas tentativas de login com falha via ssh no seu sistema. Pode haver alguém tentando usar força bruta na sua caixa (foi o caso quando recebi as mesmas mensagens no meu sistema). Leia seu var/log/auth.log para pesquisa ...

Se este for o caso, você deve considerar a instalação de uma ferramenta como 'fail2ban' ( sudo apt-get install fail2ban no Ubuntu). Ele lê automaticamente os arquivos de log do seu sistema, procura por várias tentativas de login com falha e bloqueia os clientes mal-intencionados por um tempo configurável via iptables ...

    
por 30.06.2014 / 15:08
4

Parece que a análise acima não está completamente correta. Não parece haver uma opção de repetição = para autenticação pam (eu encontrei um para pam_cracklib, mas isso só diz respeito a alterar a senha na seção "senha", não a autenticação na seção "auth" do pam). Em vez disso, o pam_unix contém um número máximo de tentativas de 3. Após três novas tentativas, o pam retorna o código de erro PAM_MAXRETRIES para informar o sshd sobre isso.

O sshd deve realmente parar de tentar neste caso, independentemente dos seus próprios MaxAuthTries. Não, o que eu acho que é um bug (que eu acaba de reportar com o openssh ).

Até que esse bug seja corrigido, parece que definir MaxAuthTries como < = 3 é a única maneira de impedir que essa mensagem seja exibida.

    
por 25.06.2014 / 12:50
1

O cliente ssh pode tentar autenticar com uma ou mais chaves. Qualquer chave que não esteja listada em authorized_keys falhará, consumindo uma das novas tentativas do sshd. O cliente tentará todas as chaves ssh que tiver até que uma tenha sucesso ou todas falhem, então é bom que o sshd permita que você tente várias.

Se nenhuma tecla corresponder, o sshd poderá permitir que você tente uma senha. Cada uma dessas tentativas também consome uma das tentativas permitidas do sshd. Mas também consome uma das tentativas permitidas do PAM.

Assim, a combinação de 6 ssh auth tenta e 3 pam auth tenta é uma coisa boa: significa que ssh permitirá 6 tentativas de total de autenticação (chave ou senha) mas apenas 3 tentativas de senha.

Como outros já disseram, se você costuma vê-los em seus registros, alguém está tentando forçar sua entrada no sistema. Considere usar o fail2ban para bloquear completamente os pacotes dos endereços IP dos quais essas tentativas se originam.

    
por 26.10.2017 / 01:44
0

Após a atualização do Debian 6 para o Debian 7, eu me deparei com os mesmos problemas. De repente, esses erros sshd surgiram no meu console.

2014 Oct 15 13:50:12 vps456 PAM service(sshd) ignoring max retries; 6 > 3
2014 Oct 15 13:50:17 vps456 PAM service(sshd) ignoring max retries; 6 > 3
2014 Oct 15 13:50:18 vps456 PAM service(sshd) ignoring max retries; 6 > 3

No meu caso, o problema era que rsyslog não estava mais instalado após o upgrade da Debian.

Depois de instalar o rsyslog, esses erros desapareceram do meu console: apt-get install rsyslog

    
por 15.10.2014 / 15:11
-1

Certamente obter esses avisos em seu console pode ser chato, mas quando vejo em meus arquivos de log que ontem tive 987 tentativas de login raiz com origem em um endereço IP na China, ou 2670 em algum serviço de nuvem na Califórnia, ou. ..muitos outros, eu não me preocupo. A raiz do usuário não tem permissão para fazer login no meu computador. Não importa quantas tentativas.

Se eles começarem a tentar nomes de usuário que possam fazer login, isso seria um assunto diferente, mas se alguém tiver boas senhas, também não vejo risco algum. As senhas de login (diferentemente das chaves de criptografia) só podem ser tentadas com tanta rapidez.

Usar algo como o fail2ban parece uma complexidade desnecessária que não compra nada (se você tiver boas senhas) e a complexidade é ruim para a segurança. As tentativas de estrangulamento são algo que o sshd deve implementar, não algo que deve requerer algum complemento ... e o sshd faz tentativas de aceleração. Bom.

-kb, o Kent que usa apenas boas senhas e nunca é reciclado entre sites diferentes.

    
por 11.11.2014 / 15:07