it-swarm-pt.tech

Muitas falhas de autenticação para * username *

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

 rsync -av -e "ssh -p2222" /home/usuário/.ssh/key.pub nomedeusuá[email protected]: .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é o momento) [remetente] 
 Erro rsync: erro inexplicável (código 255) em io.c (601) [remetente = 3.0.7] 

Eu tenho andado por aí anteriormente com o ssh até obter o erro 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 louco. 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.

248
Gabriel A. Zorrilla

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

Você pode ver isso por si mesmo adicionando o sinalizador -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 par" .

Para evitar que chaves irrelevantes sejam oferecidas, você deve especificá-lo explicitamente em cada entrada 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' [email protected]:/path/

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

ou

ssh -i some_id_rsa -o IdentitiesOnly=yes [email protected]:/path/
406
John T

Eu 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

179
Ben West

Eu estava recebendo este erro também e descobri que estava acontecendo b/c o servidor foi 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 em seu diretório ~/.ssh/ & execute ssh-add -D
  3. vincule explicitamente uma chave a um determinado Host em seu arquivo ~/.ssh/config

Igual a:

Host foo
hostname foo.example.com
IdentityFile /home/YOU/.ssh/foo
  1. Provavelmente não é uma boa maneira de fazer isso, já que isso enfraquece um pouco o servidor ssh, já que agora ele aceitará mais chaves em uma determinada tentativa de conexão. Pense nos vetores de ataque de força bruta aqui.

  2. É uma boa maneira de assumir se você possui chaves que não são necessárias e podem ser excluídas permanentemente.

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

24
slm

Eu adicionei ao ~/.ssh/config isto:

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

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 enganoso (que é um superconjunto, incluindo senha), você pode fazer isso a partir da linha de comando:

ssh -o PreferredAuthentications=password [email protected]
6
Greg Rundlett

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, em seguida, solicitará a autenticação por 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 [email protected]
5
Will Verna

Saindo do @David dizendo, apenas adicione este IdentitiesOnly yes ao seu .ssh/config, ele faz a mesma coisa que ssh -o PubkeyAuthentication=no.

Depois de efetuar 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 [email protected]_ADDR 'cat >> .ssh/authorized_keys'. Isso deve reativar seu ssh com chave pública

3
Alan Dong

Eu sei que este é um segmento antigo, mas eu só queria adicionar aqui que eu corri para a mesma mensagem de erro, mas foi causado pelo proprietário da pasta .ssh sendo raiz, em vez do usuário que estava usando a chave. Eu 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
2
Adam

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

$ chmod 750 ~;chmod 700 ~/.ssh
1
tbc0

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 que fiz o que "John T" sugeriu, recebi este erro:

Permissão negada (publickey).

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

0
Deepak Joy

Muitas falhas de autenticação

Essa mensagem é causada por muitas tentativas de autenticação com falha, dados os limites permitidos impostos 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, marque a opção MaxAuthTries (veja: man sshd_config ).

    Post relacionado: O que é uma conexão para o limite 'MaxAuthTries' do sshd_config?

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

0
kenorb

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 logar com sucesso com a minha chave.

0
Benedikt Köppel