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

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

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.

"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).

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

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.

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.

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.

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.

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 .)

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

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>

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.

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.

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".

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.

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).

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 !!

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

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.