Muitas falhas de autenticação para * username *

Question

Eu tenho uma conta do hostgator com acesso ssh ativado e ao tentar carregar o arquivo de chave .pub gerado com este comando:

rsync -av -e "ssh -p2222" /home/user/.ssh/key.pub [email protected]:.ssh/authorized_keys

Eu continuo recebendo:

Received disconnect from 111.222.33.44: 2: Too many authentication failures for username
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(601) [sender=3.0.7]

Eu tenho andado por aí com o ssh até ter a falha de autenticação. Mas agora parece que o contador de falhas auth não redefinir (estava esperando mais de 12 horas agora, suporte técnico "suponha" ele redefine após 30 min a 1 hora, e outro cara me disse "ele redefine toda vez que você tentar fazer o login com o nome de usuário ", jeesh).

Isso está me deixando louca. Eu mesmo tinha configurado isso em um servidor personalizado Slicehost e tinha menos problemas do que com esses caras. Alguma dica? Talvez seja algo do lado do cliente e não do lado do servidor.

    

Answer 1

Isso geralmente é causado por inadvertidamente oferecer várias chaves ssh ao servidor. O servidor rejeitará qualquer chave depois que muitas chaves tiverem sido oferecidas.

Você pode ver isso por si mesmo adicionando o sinal -v ao seu comando ssh para obter uma saída detalhada. Você verá que um monte de chaves é oferecido, até que o servidor rejeite a conexão dizendo: "Muitas falhas de autenticação para [usuário]" . Sem o modo detalhado, você verá apenas a mensagem ambígua "Conexão redefinida pelo ponto" .

Para evitar que chaves irrelevantes sejam oferecidas, você deve especificá-lo explicitamente em cada entrada do host no arquivo ~/.ssh/config (na máquina cliente) adicionando IdentitiesOnly da seguinte forma:

Host www.somehost.com
  IdentityFile ~/.ssh/key_for_somehost_rsa
  IdentitiesOnly yes
  Port 22

Se você usar o ssh-agent, será útil executar ssh-add -D para limpar as identidades.

Se você não estiver usando nenhuma configuração de hosts ssh, terá que especificar explicitamente a chave correta no comando ssh da seguinte forma:

ssh -i some_id_rsa -o 'IdentitiesOnly yes' them@there:/path/

Observação: o parâmetro 'IdentitiesOnly yes' deve estar entre aspas.

ou

ssh -i some_id_rsa -o IdentitiesOnly=yes them@there:/path/

    

Answer 2

Encontrei uma maneira mais fácil de fazer isso (se estiver usando a autenticação por senha):

ssh -o PubkeyAuthentication=no [email protected]

Isso força a autenticação não chave. Consegui fazer logon imediatamente.

Referência

    

Answer 3

Eu também estava recebendo este erro e descobri que estava acontecendo b / c que o servidor estava configurado para aceitar até 6 tentativas:

/etc/ssh/sshd_config
...
...
#MaxAuthTries 6

Além de definir o IdentitiesOnly yes no seu arquivo ~/.ssh/config , você tem algumas outras opções.

1. Aumentar o MaxAuthTries (no servidor ssh)
2. exclua alguns dos pares de chaves que você tem no diretório ~/.ssh/ & executar ssh-add -D
3. vincular explicitamente uma chave a um host específico no seu ~/.ssh/config file

Assim:

host foo
hostname foo.example.com
IdentityFile /home/YOU/.ssh/foo

1. Provavelmente não é uma boa maneira de fazer isso, já que ele enfraquece um pouco o servidor ssh, pois agora ele aceita mais chaves em uma determinada tentativa de conexão. Pense nos vetores de ataque de força bruta aqui.

2. É um bom caminho para assumir que você possui chaves que não são necessárias e podem ser excluídas permanentemente.

3. E a abordagem de configurar IdentitiesOnly é provavelmente a maneira preferida de lidar com essa questão!

Answer 4

Eu adicionei a ~ / .ssh / config this:

Host *
IdentitiesOnly yes

Permite a opção IdentitiesOnly = yes por padrão. Se você precisar se conectar com chave privada, você deve especificá-lo com a opção -i

    

Answer 5

Se você tiver uma senha e quiser simplesmente usar a senha para fazer login, veja como você faz isso.

Para usar SOMENTE a autenticação por senha e NÃO usar a chave pública e NÃO usar o "teclado interativo" um tanto enganador (que é um superconjunto que inclui senha), você pode fazer isso a partir da linha de comando:

ssh -o PreferredAuthentications=password [email protected]

    

Answer 6

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 diretório .ssh e se a opção '-i' não estiver especificada na linha de comando.

O cliente ssh tentará primeiro fazer o 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).

Se você tiver um número de chaves privadas em seu diretório .ssh, você pode desativar a "Autenticação de chave pública" na linha de comando, usando o argumento opcional '-o'.

Por exemplo:

$ ssh -o PubkeyAuthentication=no root@host

    

Answer 7

Saindo do @David dizendo, basta adicionar isso %código% para o seu .ssh / config, ele faz a mesma coisa que IdentitiesOnly yes

Após efetuar login, remova ssh -o PubkeyAuthentication=no. . Agora, volte para a máquina local e digite o seguinte

.ssh/authorized_keys . Isso deve reativar seu ssh com chave pública

    

Answer 8

Eu sei que este é um segmento antigo, mas eu só queria adicionar aqui que eu corri para a mesma mensagem de erro, mas foi causada pelo proprietário da pasta .ssh sendo raiz, em vez do usuário que estava usando o chave. Corrigi o problema executando os seguintes comandos:

sudo chown -R user:user /home/user/.ssh

Também verifiquei se as permissões estavam corretas na pasta .ssh:

sudo chmod 700 /home/user/.ssh

Os arquivos dentro do diretório .ssh devem ter a permissão de 600:

sudo chmod 600 /home/user/.ssh/authorized_keys

    

Answer 9

No meu caso, o problema era permissões de diretório. Isso resolveu para mim:

$ chmod 750 ~;chmod 700 ~/.ssh

    

Answer 10

No meu caso, estava acontecendo porque eu estava usando o nome de usuário "ubuntu", mas o nome de usuário nesta instância era "ec2-user"

Depois de fazer o que "John T" sugeriu, recebi este erro:

Permission denied (publickey).

Em seguida, encontrei a solução (ou seja, alterar o nome de usuário para "ec2-user") nesta resposta: link

    

Answer 11

Eu tinha minha chave pública em .ssh/authorized_keys2 , mas o servidor estava configurado para ler somente .ssh/authorized_keys :

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile .ssh/authorized_keys

Depois de mover meu arquivo para .ssh/authorized_keys , posso fazer login com sucesso com minha chave.

    

Answer 12

Too many authentication failures

Essa mensagem é causada por muitas tentativas de autenticação malsucedidas, dados os limites permitidos aplicados no servidor SSH remoto. Isso significa potencialmente que você possui muitas identidades adicionadas ao agente SSH.

Aqui estão algumas sugestões:

• Adicione -v para ver se esse é o caso (você está usando muitas identidades).
• Listar identidades adicionadas por ssh-add -l .
• Remova a identidade com falha do agente por: ssh-add -d .
• Você também pode excluir todas as identidades por ssh-add -D e adicionar novamente somente as relevantes.

• Se você tiver acesso ao servidor SSH, verifique a opção MaxAuthTries (consulte: man sshd_config ).

  ^{Post relacionado: O que é uma conexão para o limite '% MaxAuthTries' de sshd_config ?}

• Se nada disso ajudar, verifique se você está usando as credenciais ou arquivos corretos.

Answer 13

Esta mensagem pode aparecer quando o nome de usuário e a senha corretos não são inseridos.

Primeiro verifique se o usuário está listado:

vim /etc/passwd