Demasiadas falhas de autenticação para *username*

Isto é normalmente causado por oferecer inadvertidamente múltiplas chaves ssh ao servidor. O servidor rejeitará qualquer chave depois de terem sido oferecidas demasiadas chaves.

Pode ver isto por si mesmo adicionando a bandeira -v ao seu comando ssh para obter uma saída verbosa. Verá que um monte de chaves são oferecidas, até o servidor rejeitar o ditado de conexão: “Demasiadas falhas de autenticação para [utilizador]”. Sem modo verbose, apenas verá a mensagem ambígua “Connection reset by peer”.

Para evitar que chaves irrelevantes sejam oferecidas, tem de especificar isto explicitamente em cada entrada do host no ficheiro ~/.ssh/config (na máquina cliente) adicionando IdentitiesOnly assim:

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

Se usar o ssh-agent, ajuda a executar ssh-add -D para limpar as identidades.

Se não estiver a utilizar nenhuma configuração de anfitrião ssh, tem de especificar explicitamente a chave correcta no comando ssh assim:

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

Note: o parâmetro ‘IdentitiesOnly yes’ necessário para estar entre aspas.

ou

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

Encontrei uma forma mais fácil de o fazer (se utilizar autenticação por palavra-passe):

ssh -o PubkeyAuthentication=no username@hostname.com

Isto obriga a uma autenticação sem chave. Consegui aceder imediatamente. Referência

Também estava a receber este erro e descobri que estava a acontecer b/c o servidor estava configurado para aceitar até 6 tentativas:

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

Além de configurar o IdentitiesOnly yes no seu ficheiro ~/.ssh/config tem mais algumas opções.

1. Aumente o MaxAuthTries (no servidor ssh)

2. Apague alguns dos pares de chaves que tem presentes no seu directório ~/.ssh/ e corra ssh-add -D

3. Ligue explicitamente uma chave a um determinado anfitrião no seu ficheiro ~/.ssh/config

Assim:

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

1. Provavelmente não é uma boa maneira de o fazer, dado que enfraquece um pouco o seu servidor ssh, uma vez que agora vai aceitar mais chaves numa dada tentativa de ligação. Pense em vectores de ataque de força bruta aqui.

2. É uma boa maneira de ir assumindo que tem chaves que não são necessárias e podem ser permanentemente apagadas.

3. E a abordagem de definir IdentidadesApenas são provavelmente as formas preferidas de lidar com esta questão!

Adicionei a ~/.ssh/config isto:

Host *
IdentitiesOnly yes

Permite a opção IdentitiesOnly=yes por defeito. Se precisar de se ligar com chave privada, deve especificá-la com a opção -i

Se obtiver o seguinte erro SSH:

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

Isto pode acontecer se tiver (por defeito no meu sistema) cinco ou mais ficheiros de identidade DSA/RSA armazenados no seu directório .ssh e se a opção ‘-i’ não estiver especificada na linha de comandos.

O cliente ssh tentará primeiro fazer o login usando cada identidade (chave privada) e o próximo prompt para autenticação da palavra-passe. No entanto, o sshd baixa a ligação após cinco más tentativas de login (mais uma vez a predefinição pode variar).

Se tiver várias chaves privadas no seu directório .ssh pode desactivar “Public Key Authentication” na linha de comandos utilizando o argumento opcional ‘-o’.

Por exemplo:

$ ssh -o PubkeyAuthentication=no root@host

Se tem uma palavra-passe, e pretende simplesmente usar a palavra-passe para iniciar sessão, eis como o faz.

Para usar SOMENTE a autenticação da palavra-passe e NÃO usar a chave pública, e NÃO usar a “keyboard-interactiva” algo enganadora (que é um super conjunto que inclui a palavra-passe), pode fazê-lo a partir da linha de comando:

ssh -o PreferredAuthentications=password user@example.com

Ao sair @David dizendo, basta adicionar este IdentitiesOnly yes ao seu .ssh/config, ele faz a mesma coisa que ssh -o PubkeyAuthentication=no.

Depois de fazer login, remova o .ssh/authorized_keys. Agora, volte à máquina local e digite o seguinte

cat ~/.ssh/id_rsa.pub | ssh -o PubkeyAuthentication=no user@IP_ADDR 'cat >> .ssh/authorized_keys'. Isto deverá voltar a activar o seu ssh com chave pública

Sei que este é um tópico antigo, mas queria apenas acrescentar aqui que encontrei a mesma mensagem de erro, mas foi causado pelo facto de o proprietário da pasta .ssh ser o root e não o utilizador que estava a utilizar a chave. Corrigi o problema executando os seguintes comandos:

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

Também me certifiquei que 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

No meu caso, o problema eram as permissões de directório. Isto resolveu-o para mim:

$ chmod 750 ~;chmod 700 ~/.ssh

Esta foi uma diversão para mim. Acontece que mudei a minha password localmente enquanto estava num modo de localização diferente de um teclado que estava a usar para fazer o login remotamente. Isto efectivamente tornou a minha palavra-passe diferente do que eu pensava que era provavelmente porque um dos meus caracteres especiais era diferente do que o teclado dizia que era.

Demasiadas falhas de autenticação

Esta mensagem é causada por haver demasiadas tentativas de autenticação falhadas, dados os limites permitidos no servidor SSH remoto. Isto significa potencialmente que tem demasiadas identidades adicionadas no agente SSH.

Aqui estão algumas sugestões:

• Adicionar -v para ver se é esse o caso (tem usado demasiadas identidades).
• Listar identidades adicionadas por ssh-add -l.
• Remover a identidade falhada do agente por: ssh-add -d.
• Também pode apagar todas as identidades por ssh-add -D e readmitir apenas uma relevante.

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

• Se nada disto ajudar, verifique se está a utilizar as credenciais ou ficheiro correctos.

Eu tinha a minha chave pública em .ssh/authorized_keys2, mas o servidor foi configurado para ler apenas .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 o meu ficheiro para .ssh/authorized_keys, posso iniciar sessão com sucesso com a minha chave.

No meu caso, estava a acontecer porque estava a usar o nome de utilizador “ubuntu”, mas o nome de utilizador neste caso era “ec2-user”

Depois de ter feito o que “John T” sugeriu, recebi este erro:

Permissão negada (publickey).

Depois encontrei a solução (i.e. mudar o nome de utilizador para “ec2-user”) nesta resposta: https://stackoverflow.com/questions/1454629/aws-ssh-access-permission-denied-publickey-issue

Esta mensagem pode aparecer quando o nome de utilizador e a palavra-passe correctos não são introduzidos.

Primeiro verifique se o utilizador está listado:

vim /etc/passwd