Demasiadas falhas de autenticação para * nome de usuário *

Eu tenho uma conta hostgator com o acesso ssh ativado. Ao tentar fazer upload do arquivo-chave .pub gerado com este comando:

rsync -av -e "ssh -p2222" /home/user/.ssh/key.pub username@111.222.33.44:.ssh/authorized_keys

Eu continuo recebendo:

Desconexão recebida de 111.222.33.44: 2: muitas falhas de autenticação para o nome de usuário
rsync: conexão inesperadamente fechada (0 bytes recebidos até agora) [remetente]
Erro rsync: erro inexplicável (código 255) em io.c (601) [remetente = 3.0.7]

Eu estive brincando anteriormente com o ssh até obter a falha de autenticação. Mas agora parece que o contador de falhas de autenticação não é redefinido (aguardando mais de 12 horas, o suporte técnico "supõe que seja redefinido após 30 minutos a 1 hora e outro cara me disse" é redefinido toda vez que você tenta fazer o login com o nome de usuário ", jeesh).

Isso está me deixando louco. Eu até tinha isso configurado em um servidor personalizado do 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.

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

Você pode ver isso adicionando a -vflag ao seu sshcomando para obter uma saída detalhada. Você verá que várias chaves são oferecidas, até que o servidor rejeite a conexão dizendo: "Muitas falhas de autenticação para o [usuário]" . Sem o modo detalhado, você verá apenas a mensagem ambígua "Conexão redefinida pelo par" .

Para impedir que chaves irrelevantes sejam oferecidas, você deve especificar isso explicitamente em todas as entradas do host no ~/.ssh/configarquivo (na máquina cliente), adicionando IdentitiesOnlyo seguinte:

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 -Dpara limpar as identidades.

Se você não estiver usando nenhuma configuração de hosts ssh, precisará especificar explicitamente a chave correta no sshcomando da seguinte maneira:

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

Nota: o parâmetro 'IdentitiesOnly yes' precisava estar entre aspas.

ou

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

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

ssh -o PubkeyAuthentication=no username@hostname.com

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

Referência

Eu também estava recebendo esse erro e descobri que estava acontecendo porque o servidor estava configurado para aceitar até 6 tentativas:

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

Além de definir a IdentitiesOnly yessua ~/.ssh/configarquivo que você tem um par de outras opções.

1. Aumente o MaxAuthTries(no servidor ssh)
2. exclua alguns dos pares de chaves que você tem presente em seu ~/.ssh/diretório e executessh-add -D
3. vincular explicitamente uma chave a um determinado host em seu ~/.ssh/configarquivo

Igual a:

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

1. Provavelmente não é uma boa maneira de fazê-lo, pois enfraquece um pouco o servidor ssh, já que 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 desde que você tenha chaves desnecessárias e que possam ser excluídas permanentemente.

3. E a abordagem de definir o IdentitiesOnly provavelmente é a maneira preferida de lidar com esse problema!

Eu adicionei ao ~ / .ssh / config isso:

Host *
IdentitiesOnly yes

Ativa a opção IdentitiesOnly = yes por padrão. Se você precisar se conectar com a chave privada, especifique-a com a opção -i

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 e se a opção '-i' não estiver 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).

Se você tiver várias chaves privadas em seu diretório .ssh, poderá 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

Se você possui uma senha e deseja simplesmente usá-la para efetuar login, eis como você o faz.

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

ssh -o PreferredAuthentications=password user@example.com

Saindo do @David dizendo, basta adicionar isso IdentitiesOnly yes ao seu .ssh / config, ele faz a mesma coisa quessh -o PubkeyAuthentication=no.

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

cat ~/.ssh/id_rsa.pub | ssh -o PubkeyAuthentication=no user@IP_ADDR 'cat >> .ssh/authorized_keys'. Isso deve reativar seu ssh com chave pública

Eu sei que esse é um encadeamento antigo, mas eu só queria acrescentar aqui que encontrei a mesma mensagem de erro, mas foi causada pelo proprietário da pasta .ssh ser raiz e não pelo usuário que estava usando a 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 no diretório .ssh devem ter a permissão 600:

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

No meu caso, o problema eram as permissões de diretório. Isso corrigiu para mim:

$ chmod 750 ~;chmod 700 ~/.ssh

No meu caso, isso 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:

Permissão negada (chave pública).

Então eu encontrei a solução (ou seja, alterando o nome de usuário para "ec2-user") nesta resposta: https://stackoverflow.com/questions/1454629/aws-ssh-access-permission-denied-publickey-issue

Eu tinha minha chave pública .ssh/authorized_keys2, mas o servidor estava configurado para somente leitura .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 efetuar login com sucesso com minha chave.

Muitas falhas de autenticação

Essa mensagem é causada por muitas tentativas de autenticação com falha, devido aos limites permitidos impostos no servidor SSH remoto. Isso significa potencialmente que você adicionou muitas identidades no agente SSH.

Aqui estão algumas sugestões:

• Adicione -vpara ver se é esse o caso (você está usando muitas identidades).
• Listar identidades adicionadas por ssh-add -l.
• Remover falhando identidade do agente por: ssh-add -d.
• Você também pode excluir todas as identidades ssh-add -De adicionar novamente apenas uma relevante.

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

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

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

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