Tem certeza de que o login root para ssh é permitido?
Verifique o sshd_config e verifique se o login root é permitido. O sshd precisará ser reiniciado se a configuração mudar.
Eu fiz várias tentativas para estabelecer conexão SSH para o usuário root @ host usando o terminal de putty. Ao fazer isso, eu especifiquei credenciais erradas várias vezes e depois disso eu as especifiquei corretamente, e depois que as credenciais foram aceitas, a sessão ssh quebra com
"Server unexpectedly closed network connection".
Esse erro é relatado pelo terminal de putty. Ao tentar ssh root @ localhost a partir do console local - ele funciona bem. Ele também funciona bem quando eu ssh otheruser @ host de outro host. Portanto, os problemas de conectividade de rede não são culpados. O único erro que estou pensando é: "Muitas falhas de autenticação para o usuário root" , embora o putty tenha relatado um erro diferente.
A questão é: como recuperar-se desta condição de erro e deixar o putty login novamente? Reiniciar o sshd parece não ajudar
"Muitas falhas de autenticação para raiz do usuário" significa que o limite de MaxAuthTries do servidor SSH foi excedido . Isso acontece para que seu cliente esteja tentando autenticar com todas as chaves possíveis armazenadas em /home/USER/.ssh/.
Esta situação pode ser resolvida da seguinte forma:
Host host IdentityFile /home/USER/.ssh/id_rsa Host host2 IdentityFile /home/USER/.ssh/id_rsa2 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 no diretório .ssh . Nesse caso, se a opção -i não for especificada na linha de comando, o cliente ssh tentará primeiro efetuar login usando cada identidade (chave privada) e o próximo prompt para autenticação de senha. No entanto, o sshd descarta a conexão após cinco tentativas de login incorretas (novamente, o padrão pode variar).
Portanto, se você tiver várias chaves privadas em seu diretório .ssh, poderá desativar Public Key Authentication na linha de comando usando o argumento -o 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. Servidor verificando passo a passo cada chave e se MaxAuthTries está configurado em 3, em seguida, após as 3 primeiras tentativas desconectará você. Segurança ssh típica.
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 sua perda de tempo. Primeiro tente analisar o problema, coletar informações e depois perguntar.
Divirta-se.
Esta é uma prática ruim. Basta ter um usuário regular na caixa remota e conectar-se por meio do ssh usando-o e, em seguida, obter acesso root usando su / sudo.
Para mim, esse problema foi resolvido criando o ssh_config abaixo para o host ao qual eu 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 pasta ~/.ssh , como 16 ou mais. E sem as duas diretivas IdentityFile AND IdentitiesOnly na configuração, minha máquina aparentemente estava testando todas as chaves em ~/.ssh e atingindo o número máximo de tentativas antes de tentar o IdentityFile correto.
Eu recomendo que você, como Anon acima postou, use outro usuário para obter acesso ssh e use o comando su para ganhar root access.
Certifique-se também de ativar PermitRootLogin no arquivo /etc/ssh/sshd_config no servidor.
Corrigi este problema em meus sistemas executando os seguintes comandos:
eval $(ssh-agent)
ssh-add ~/.ssh/keyname
Então tente o ssh na máquina remota
Eu também enfrentei o mesmo problema. Isso pode acontecer facilmente se você estiver usando Pageant e tiver um grande número de chaves carregadas nele , pois esses servidores contam cada oferta de chave pública como uma tentativa de autenticação.
(Este conselho foi retirado de aqui .)
Eu fui mordido por um problema semelhante.
No entanto, a causa real era que eu tinha ForwardAgent yes no 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 causado por um ter o encaminhamento ativo. Então, C foi o primeiro a receber todas as chaves de A e só então as de B.
Apareceu de repente quando adicionei mais uma tecla a A
Corrigi este problema no meu Mac:
Para resolver temporariamente esse problema até que as coisas possam ser totalmente tratadas, conforme observado em outro lugar, você pode redefinir o registro PAM de um usuário para que ele possa tentar novamente:
pam_tally --reset --user <USERNAME>
pam_tally2 --reset --user <USERNAME>
OK, então no meu caso isso foi bem esquisito, aqui vai ...
Eu tenho uma VM vagrant padrão com uma chave SSH e posso usar o SSH nela usando o Putty. Ao tentar obtê-lo durante a implantação no PHPStorm, recebo too many authentication failures error. Então eu aumentei o MaxAuthTries no meu sshd_config e então fui atingido com Auth failed erro e então 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 no PHPStorm. Então foi assim:
C:\Users\Deadpool\.ssh\chimichanga
e agora é assim:
C:\Users\Deadpool\.ssh\chimichanga.
E funciona ... Na minha pasta ".ssh" eu tenho mais arquivos:
chimichanga - copy of "id_rsa" from vagrant machine
chimichanga.ppk
chimichanga.pub
Não tenho certeza do que esse ponto fcuking faz, mas usar o arquivo .ppk não funciona, então acho que é meio mágico;) Ah, e eu poderia me livrar dos MaxAuthTries depois desse "truque de pontos".
Eu resolvi este problema com dois passos simples no meu servidor Ubuntu 16.04 -
Primeiro, pare meu servidor vnc ou mate o processo -
vncserver -kill :1
e, em seguida, inicie-o novamente -
vncserver
Depois disso, conecte-o a partir do cliente de área de trabalho remota -
999.99.99.99:5901
Feito !!
Outras respostas indicam a melhor maneira de se conectar como root e as implicações de segurança disso, mas sua pergunta explícita foi
how to recover from this error condition and let putty login again?
Você mencionou na última vez que você se conectou, então o servidor remoto soltou a conexão.
O que eu acho que você pode encontrar é que o servidor remoto está executando o fail2ban (*) e ele "prendeu" seu IP após o login bem-sucedido. Você pode testar isso tentando fazer login novamente e nem obterá o prompt de login.
Existem duas soluções, você pode esperar o tempo de prisão, em que as coisas simplesmente voltam ao normal, mas o tempo de prisão pode ser qualquer coisa. Ou você pode encontrar outro computador para fazer o login, fazer isso e "não-jail" seu IP, neste caso "diferente" é da perspectiva do servidor remoto, então outro computador atrás do mesmo firewall provavelmente não funcionará também .
(*) O fail2ban é um daemon super prático que pode verificar periodicamente vários arquivos de log e ajustar regras de firewall para fazer com que o servidor "desapareça" quando detectar comportamento potencialmente mal-intencionado de um cliente. No debian, ele sai da caixa configurada para detectar vários logins ssh com falha de um determinado IP, e depois de 3 (eu acho) ele descartará todos os pacotes desse IP. Funciona brilhantemente para impedir esses ataques de força bruta com scripts.
siga as etapas abaixo para a resolução
E verifique novamente após as alterações acima
Eu tive o mesmo problema em que continuei recebendo "SServer enviado tipo de mensagem desconectada 2 (erro de protocolo): Muitas falhas de autenticação para o usuário"
Eu resolvi esse problema removendo todas as minhas chaves ssh (.ppk) e, em seguida, conectei-me ao servidor integrado do AD.