Como recuperar de "Muitas falhas de autenticação para raiz do usuário"

64

Eu fiz várias tentativas para estabelecer o SSH-connecton para o usuário root @ host usando o terminal putty. Ao fazer isso, especifiquei credenciais erradas várias vezes e depois especifiquei-as corretamente e, depois que as credenciais foram aceitas, a sessão ssh é interrompida com

"Servidor encerrado inesperadamente na conexão de rede".

Este erro é relatado pelo terminal putty. Ao tentar ssh root @ localhost no console local - ele funciona bem. Também funciona bem quando ssh otheruser @ host de outro host. Portanto, problemas de conectividade de rede não são culpados. O único erro em que estou pensando é: "Muitas falhas de autenticação para a raiz do usuário", embora o putty tenha relatado um erro diferente.

A questão é: como se recuperar dessa condição de erro e deixar o putty fazer login novamente? Reiniciar o sshd parece não ajudar

user11722
fonte
11
Certifique-se de desativar o seu agente ssh (por exemplo, concurso no Windows) se você receber um Too many Authentication Failureserro antes de poder efetuar o login.
Mahn 30/03

Respostas:

8

Você tem certeza de que o login root no ssh é permitido?

Verifique sshd_config e verifique se o login raiz é permitido. O sshd precisará ser reiniciado se a configuração for alterada.

damorg
fonte
120

"Demasiadas falhas de autenticação para raiz do usuário" significa que o limite MaxAuthTries do servidor SSH foi excedido . Isso acontece para que seu cliente esteja tentando se autenticar com todas as chaves possíveis armazenadas em /home/USER/.ssh/.

Essa situação pode ser resolvida das seguintes maneiras:

  1. ssh -i / caminho / para / id_rsa root @ host
  2. Especifique o par Host / IdentityFile em /home/USER/.ssh/config .
    • Host host
    • IdentityFile /home/USER/.ssh/id_rsa
    • Host host2
    • IdentityFile /home/USER/.ssh/id_rsa2
  3. Aumente o valor MaxAuthTries no servidor SSH em / etc / ssh / sshd_config (não recomendado).
Peta Sittek
fonte
9
Esta deve realmente ser a resposta aceita!
Benjamin
4
Para ser uma resposta aceita, a resposta realmente teria que ser sobre o software mencionado na pergunta. =)
rakslice
4
Outra causa do limite ser excedido pode ser seu agente ssh. ssh -vvmostrou várias versões de duas chaves (fornecidas pelo ssh-agent) sendo testadas. Suponho que isso se deva a reinicialização com pouca frequência e a substituição de algumas chaves que expiraram; aparentemente o ssh-agent não substitui as chaves antigas pelas novas. Eu matei o ssh-agent e o problema desapareceu.
Mark
Que inconveniente haveria de aumentar MaxAuthTries? Duvido que muitos ataques sejam realizados ao tentar várias chaves diferentes. Além disso, se um invasor quiser fazer isso, ele pode simplesmente fechar a conexão e abrir uma nova sempre que atingir o limite. Eles não conseguirão forçar brutalmente uma chave de qualquer maneira.
precisa saber é o seguinte
@ Mark Obrigado! Reiniciar o ssh-agent corrigiu isso para mim!
winduptoy
91

Se você receber o seguinte erro SSH:

$ Received disconnect from host: 2: Too many authentication failures for root

Isso pode acontecer se você tiver (padrão no meu sistema) cinco ou mais arquivos de identidade DSA / RSA armazenados em seu .sshdiretório. Nesse caso, se a -iopção não for especificada na linha de comando, o cliente ssh tentará primeiro fazer login usando cada identidade (chave privada) e o próximo prompt para autenticação de senha. No entanto, o sshd interrompe a conexão após cinco tentativas incorretas de login (novamente o padrão pode variar).

Portanto, se você tiver várias chaves privadas no diretório .ssh, poderá desativar Public Key Authenticationna linha de comando usando o -oargumento opcional.

Por exemplo:

$ ssh -o PubkeyAuthentication=no root@host
Will Verna
fonte
11
Muito obrigado! Usando o Ubuntu Server aqui, que eu posso acessar apenas por SSH. Eu havia definido "MaxAuthTries 1" depois de seguir cegamente um tutorial na internet.
Andre Figueiredo
Você acabou de salvar minha vida! Não usando a autenticação de chave, então as outras respostas não estavam ajudando. Isso resolveu muuuuito facilmente !!
George Green
5
Esta é a resposta
smac89
Simplesmente copiei a chave novamente, usando a autenticação por senha, e agora funciona sempre. Eu tenho muitas chaves no meu .sshdiretório, acho que não é a quantidade que importa.
Ken Sharp
Esta é a resposta mais relevante e realmente deve ser o comportamento padrão para ssh-copy-id, portanto, se eu gostaria de copiar meu ID para um servidor, ele geralmente não está lá. Mas se o ssh tentar primeiro se autenticar no servidor usando pubkey, o servidor interromperá a conexão antes de poder digitar a senha.
Sprinterfreak
17

Na máquina remota, abra / etc / sshd_config e altere o valor

MaxAuthTries 30

Esse é um problema típico quando você instala várias chaves ou abre várias conexões. A verificação do servidor passo a passo de cada tecla e se MaxAuthTries estiver configurada em 3, depois das 3ª tentativas iniciais o desconectará. Segurança ssh típica.

Eu sugiro que você use o modo detalhado durante a conexão com a máquina remota para analisar o problema.

ssh -v -p port_number user @ servername

Adivinhar como a maioria das pessoas neste fórum é ERRADO e está perdendo tempo. Primeiro tente analisar o problema, colete informações e depois pergunte.

Diverta-se.


fonte
No meu caso específico, o problema era que eu estava conectado com o encaminhamento do agente, tentando executar um script que usava sua própria identidade SSH. Quando eu o executei com o encaminhamento de agente, havia muitas identidades antes de tentar ser sua. Então, configurei o script para jogar fora o ambiente do agente e isso o esclareceu. Eu também poderia ter aumentado o MaxAuthTries, mas não precisava nesse caso.
Sean Reifschneider 21/11
11
Obrigado. -vmostrei meu cliente ssh tentando usar várias chaves (eu tenho algumas agora). Eu os limpei do agente comssh-add -D
joeytwiddle
12

Isso é uma prática ruim. Apenas tenha um usuário comum na caixa remota e conecte-se através do ssh usando-o, e obtenha acesso root usando su / sudo.

Anônimo
fonte
10

Para mim, esse problema foi resolvido criando o ssh_config abaixo para o host ao qual estava me conectando.

(~ / .ssh / config)

Host example
HostName example.com
User admin
IdentityFile ~/path/to/ssh_key_rsa
IdentitiesOnly=yes

O problema ocorreu porque eu tenho muitas chaves ssh na minha ~/.sshpasta, como 16 ou mais. E sem as duas diretivas IdentityFileAND IdentitiesOnlyna configuração, minha máquina aparentemente estava tentando todas as chaves ~/.sshe atingindo o número máximo de tentativas antes de tentar o IdentityFile correto.

Ninjaxor
fonte
6

Eu recomendaria que, como o Anon postou acima, use outro usuário para obter acesso ssh e use o sucomando para obter rootacesso.

Certifique-se também de ativar PermitRootLogino /etc/ssh/sshd_configarquivo no servidor.

Roedor43
fonte
5

Eu também enfrentei o mesmo problema. Isso pode acontecer facilmente se você estiver usando o Pageant e tiver um grande número de chaves carregadas nele , pois esses servidores contam cada oferta de uma chave pública como uma tentativa de autenticação.

(Este conselho é retirado daqui .)

Prabath Dolawatta
fonte
11
Não estamos muito interessados ​​em respostas somente para links por aqui, à medida que os links apodrecem e a resposta se torna inútil. Mantenha o link, por todos os meios, mas se você puder resumir a solução em um ou dois parágrafos, poderá ter uma resposta positiva aqui.
MadHatter
2
Espero que você perdoe minha edição subsequente; agora (espero), deixa claro que o conselho a que você se refere é o conselho que você dá, mas ainda credita a fonte original. +1 de mim por tentar melhorar sua resposta!
21917 MadHatter
Também tive o problema "Muitas falhas de autenticação" no Putty. Depois de remover todas as outras chaves do PageAnt, finalmente efetuei login com sucesso.
klor 6/06
4

Corrigi esse problema em meus sistemas executando os seguintes comandos:

eval $(ssh-agent)
ssh-add  ~/.ssh/keyname

Então tente ssh na máquina remota

Sunil shakya
fonte
3

Para resolver esse problema temporariamente até que as coisas possam ser totalmente resolvidas, conforme observado em outro lugar, você pode redefinir a contagem de PAM de um usuário para que ele possa tentar novamente:

pam_tally --reset --user <USERNAME>
pam_tally2 --reset --user <USERNAME>
andyfeller
fonte
2

Fui mordido por um problema semelhante. No entanto, a verdadeira causa foi que eu tinha ForwardAgent yesno arquivo de configuração de uma máquina ao longo do pipe. Eu estava conectando da máquina A na máquina B na máquina C.

A mensagem de erro foi mostrada na tentativa ssh de B -> C, mas foi causada por A ter o encaminhamento ativo. Então, C recebeu primeiro todas as chaves de A e somente depois as de B.

De repente, apareceu quando adicionei mais uma chave ao A.

Igor Stoppa
fonte
1

Corrigi esse problema no meu Mac:

  1. definindo a senha root com "sudo passwd root" e
  2. editando e salvando o arquivo de configuração ssh com "nano / etc / ssh_config" e
  3. alterando o RSAAuthentication para "no" em vez de yes.
tallbr00
fonte
0

OK, então no meu caso isso foi bem estranho, aqui vai ...

Eu tenho uma VM vagabunda padrão com uma chave SSH e posso usá-la usando Putty. Ao tentar fazer isso durante a implantação no PHPStorm, recebo um too many authentication failureserro. Então eu aumentei o valor MaxAuthTriesno meu sshd_confige depois fui atingido com Auth failederro e depois Auth cancel.

Agora, não sei exatamente por que tentei isso, mas ... Adicionei o ponto no final do caminho da chave SSH na janela de implantação do PHPStorm. Então foi assim:

C:\Users\Deadpool\\.ssh\chimichanga

e agora é assim:

C:\Users\Deadpool\\.ssh\chimichanga.

E funciona ... Na minha pasta ".ssh" tenho mais arquivos:

chimichanga - copy of "id_rsa" from vagrant machine
chimichanga.ppk
chimichanga.pub

Não tenho certeza do que esse ponto ruim faz, mas usar o .ppkarquivo não funciona, então acho que é meio mágico;) Ah, e eu poderia me livrar do MaxAuthTries depois desse "truque de pontos".

Adam Witorean
fonte
0

Outras respostas indicam a melhor maneira de conectar-se como root e as implicações de segurança disso, mas sua pergunta explícita foi

como recuperar essa condição de erro e deixar o putty entrar novamente?

Você mencionou na última vez que se conectou, o servidor remoto interrompeu a conexão.

O que eu acho que você pode achar é que o servidor remoto está executando fail2ban (*) e "prendeu" seu IP após o login bem-sucedido. Você pode testar isso tentando fazer login novamente e nem receberá o prompt de login.

Existem duas soluções: você pode esperar o tempo de prisão, quando as coisas simplesmente voltam ao normal, mas o tempo de prisão pode ser qualquer coisa. Ou você pode encontrar um computador diferente para fazer login, fazer isso e "liberar" o seu IP; nesse caso, "diferente" é da perspectiva do servidor remoto; portanto, outro computador atrás do mesmo firewall provavelmente também não funcionará. .

(*) fail2ban é um daemon super útil que pode verificar periodicamente vários arquivos de log e ajustar as regras de firewall para fazer o servidor "desaparecer" quando detectar um comportamento potencialmente malicioso de um cliente. No debian, ele sai da caixa configurado para detectar vários logins ssh com falha de um IP específico, e após 3 (acho) ele descartará todos os pacotes desse IP. Funciona de maneira brilhante para impedir ataques de força bruta com script.

Sofredor
fonte
0

Como o @sufferer mencionado em outra resposta, algumas distribuições Linux incluem monitores para proteger contra ataques de força bruta em serviços externos visíveis como SSH, por exemplo DenyHostsou fail2ban. Esses monitores verificam os arquivos de log procurando por tentativas com falha e adicionam filtros para bloquear endereços IP com muitas falhas (o número é configurável e independente da configuração do sshd).

Se sua distribuição incluir fail2ban, quais serviços protegem a adição de regras ao firewall do iptables, você pode verificar quais serviços ou "prisões" são supervisionados usando o comando:

sudo fail2ban-client status

A prisão para o serviço SSH é sshd, portanto, para verificar se há IPs proibidos, você pode usar:

sudo fail2ban-client status sshd

e desbanir alguns IP abcd:

sudo fail2ban-client set sshd unbanip a.b.c.d

Se você tiver DenyHosts, a lista banida está no arquivo /etc/hosts.deny; você pode editar este arquivo diretamente como raiz. Para conceder algum acesso permanente ao IP abcd, você pode adicionar a linha sshd:a.b.c.dao arquivo /etc/hosts.allow.

Como sempre, o mancomando é seu amigo:

man fail2ban
man hosts.deny

Devem existir outros utilitários semelhantes, mas eu apenas os usei.

Observe que aumentar o número de tentativas permitidas na configuração do sshd não libera IPs proibidos, apenas permite mais falhas na mesma conexão. Se o número permitido for excedido, o usuário / atacante simplesmente se reconectará novamente para tentar n vezes mais.

Outros serviços tiveram a lista de proibições integrada (como mostrado na resposta de Rajnesh Thakur sobre como reiniciar o servidor VNC).

Fjor
fonte
-2

Resolvi esse problema com duas etapas simples no meu servidor Ubuntu 16.04 -

Primeiro pare meu servidor vnc ou interrompa o processo -

vncserver -kill :1

e depois inicie novamente -

vncserver

Depois disso, conecte-o no cliente Remote Desktop -

192.0.2.99:5901

Feito !!

Rajnesh Thakur
fonte
Isso não tem nada a ver com a pergunta.
Ken Sharp
-3

siga as etapas abaixo para resolução

  1. Faça backup de / etc / ssh / sshd_config
  2. Aumentar o valor de MaxAuthTries em sshd_config
  3. stopsrc -s sshd; winsrc -s sshd

E verifique novamente após as alterações acima

Arun Mathuria
fonte
-4

Eu tive o mesmo problema em que ficava recebendo "SServer enviou mensagem desconectada tipo 2 (erro de protocolo): muitas falhas de autenticação para o usuário"

Resolvi esse problema removendo todos os meus ssh (chaves .ppk) e depois conectados ao servidor integrado do AD.

Eskimo-Jbk
fonte
Esta resposta não é útil e é recomendável remover arquivos .ppk. Por favor, pessoal, se você acha que precisa remover arquivos .ppk (e não consigo pensar em um bom motivo para fazê-lo), renomeie-os para outra coisa, não os exclua. Eles contêm suas chaves, das quais você provavelmente precisa.
Law29