Questão 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/user/.ssh/key.pub nome de usuário@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 nome de usuário
rsync: conexão inesperadamente fechada (0 bytes recebidos até agora) [remetente]
Erro de 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.


223


origem




Respostas:


Isso geralmente é causada pelo inadvertidamente oferecendo 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 -v bandeira para o seu ssh comando para obter 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 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 todas as entradas do host no ~/.ssh/config (no computador cliente) arquivo adicionando IdentitiesOnly igual a:

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

Se você usa o ssh-agent, isso ajuda a 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 ssh comando assim:

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

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

ou

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

359



Não está claro para mim onde colocar essa linha. No servidor em que estou tentando efetuar login, o .ssh / config possui apenas informações para outros servidores. Você quer dizer que isso deve ir no arquivo .ssh / config no computador que eu estou tentando ssh? Se assim for, isso não está claro porque sua resposta diz "uma vez que você está logado de volta ..." - David LeBauer
Eu tenho que colocar a opção entre aspas duplas, assim: ssh -i some_id_rsa -o "IdentitiesOnly yes" them@there:/path/ - knb
Usuários do Windows executando o PAGENT (Putty Agent), verifique se você tem apenas as chaves necessárias. Eu corri para este problema depois de acidentalmente carregar todas as minhas chaves privadas. - Chris Rasco
No entanto, para sshfs (fusível) Eu tenho que escrever a opção com um sinal de igual obrigatório, assim: sshfs -o "IdentitiesOnly=yes" -o IdentityFile=~/.ssh/id_dsa them@there/var/tmp /mnt/tmp  (Ubuntu 13.10) - knb
pode ser usado sem aspas, assim: -o IdentitiesOnly=yes - Valentin Kantor


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

ssh -o PubkeyAuthentication=no username@hostname.com

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

Referência


159



+1, desejo poder te dar mais. Raspberry Pi é o único dispositivo que eu ssh em sem chave pública. Estava ficando: "Muitas falhas de autenticação para pi" - blak3r
E usar isso com rsync: rsync -av -e 'ssh -o PubkeyAuthentication=no' 'user@host.com:~/remote_file' 'local_file' - Ciro Santilli 新疆改造中心 六四事件 法轮功
Você também pode criar um Alias ​​para torná-lo ainda mais rápido para a senha auth. alias sshp = 'ssh -o PubkeyAuthentication = no' - dhempler


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 na tua ~/.ssh/config arquivo você tem algumas outras opções.

  1. Aumentar o MaxAuthTries (no servidor ssh)
  2. excluir alguns dos pares de chaves que você tem em seu ~/.ssh/ diretório e executar ssh-add -D 
  3. vincular explicitamente uma chave a um determinado host em seu ~/.ssh/config Arquivo

Igual a:

host foo
hostname foo.example.com
IdentityFile /home/YOU/.ssh/foo
  1. Provavelmente não é uma boa maneira de fazer isso, pois 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 que 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



Na sua última linha você tem o arquivo de identificação /home/YOU/.ssh/foo mas deve ser um arquivo de identidade (não é f) - Nin
@Nin - obrigado, consertado. - slm


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

Para usar APENAS 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 user@example.com

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 em 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 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).

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

5



Isso foi exatamente o que estava acontecendo comigo! Muito obrigado pela explicação;) - El Ninja Trepador


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

Depois de logado, 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


2





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

Eu também me certifiquei de 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

2



Eu tomaria cuidado ao usar isso sem uma ressalva. As permissões de chave SSH geralmente são restritas a 400 para algumas chaves, em particular, para a AWS. Ao tentar defini-los acima, isso fará com que a chave não seja aceita, e isso pode impedi-lo de sair da sua conta da AWS. - Michael Ryan Soileau


Eu adicionei a ~ / .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


2