Troppi errori di autenticazione per * nome utente *

Ho un account hostgator con accesso ssh abilitato. Quando si tenta di caricare il file chiave .pub generato con questo comando:

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

Continuo a ricevere:

Disconnessione ricevuta da 111.222.33.44: 2: troppi errori di autenticazione per il nome utente
rsync: connessione chiusa inaspettatamente (0 byte ricevuti finora) [mittente]
Errore rsync: errore inspiegabile (codice 255) su io.c (601) [mittente = 3.0.7]

Ho già giocato con ssh fino a quando non ho avuto il fallimento dell'autorizzazione. Ma ora sembra che il contatore degli errori di autenticazione non si reimposti (è in attesa da più di 12 ore, il supporto tecnico "suppone" che si reimposti dopo 30 minuti a 1 ora e un altro mi ha detto "si reimposta ogni volta che si tenta di accedere con il nome utente ", jeesh).

Questo mi sta facendo impazzire. Ho persino installato questo in un server personalizzato Slicehost e ho avuto meno problemi rispetto a questi ragazzi.

Qualche consiglio? Forse è qualcosa sul lato client e non sul lato server.

Questo di solito è causato offrendo inavvertitamente più chiavi ssh al server. Il server rifiuterà qualsiasi chiave dopo che sono state offerte troppe chiavi.

Si può vedere questo per voi stessi con l'aggiunta della -vbandiera per il vostro sshcomando per ottenere output dettagliato. Vedrai che vengono offerte alcune chiavi, fino a quando il server rifiuta la connessione dicendo: "Troppi errori di autenticazione per [utente]" . Senza modalità dettagliata, verrà visualizzato solo il messaggio ambiguo "Connessione reimpostata dal peer" .

Per evitare che vengano offerte chiavi non pertinenti, è necessario specificarlo esplicitamente in ogni voce host nel file ~/.ssh/config(sul computer client) aggiungendo in questo IdentitiesOnlymodo:

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

Se usi ssh-agent, aiuta a correre ssh-add -Dper cancellare le identità.

Se non si utilizza alcuna configurazione di host ssh, è necessario specificare esplicitamente la chiave corretta nel sshcomando in questo modo:

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

Nota: il parametro 'IdentitiesOnly yes' doveva essere tra virgolette.

o

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

Ho trovato un modo più semplice per farlo (se si utilizza l'autenticazione con password):

ssh -o PubkeyAuthentication=no username@hostname.com

Ciò impone l'autenticazione non chiave. Sono stato in grado di accedere immediatamente.

Riferimento

Stavo ricevendo anche questo errore e ho scoperto che stava accadendo in b / c il server è stato configurato per accettare fino a 6 tentativi:

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

Oltre a impostare IdentitiesOnly yesnel tuo ~/.ssh/configfile hai un paio di altre opzioni.

1. Aumenta il MaxAuthTries(sul server ssh)
2. cancella alcune delle coppie di chiavi presenti nella tua ~/.ssh/directory ed eseguissh-add -D
3. collega esplicitamente una chiave a un determinato host nel tuo ~/.ssh/configfile

Così:

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

1. Probabilmente non è un buon modo per farlo, dato che indebolisce un po 'il tuo server SSH poiché ora accetterà più chiavi in ​​un determinato tentativo di connessione. Pensa ai vettori di attacchi di forza bruta qui.

2. È un buon modo di procedere supponendo che tu abbia chiavi che non sono necessarie e che possono essere eliminate in modo permanente.

3. E l'approccio per impostare IdentitiesSolo sono probabilmente i modi preferiti per affrontare questo problema!

Ho aggiunto a ~ / .ssh / config this:

Host *
IdentitiesOnly yes

Abilita l'opzione IdentitiesOnly = yes per impostazione predefinita. Se è necessario connettersi con chiave privata, è necessario specificarlo con l'opzione -i

Se viene visualizzato il seguente errore SSH:

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

Questo può accadere se hai (di default sul mio sistema) cinque o più file di identità DSA / RSA memorizzati nella tua directory .ssh e se l'opzione '-i' non è specificata nella riga di comando.

Il client ssh tenterà innanzitutto di accedere utilizzando ciascuna identità (chiave privata) e il successivo prompt per l'autenticazione della password. Tuttavia, sshd interrompe la connessione dopo cinque tentativi di accesso errati (di nuovo il valore predefinito può variare).

Se hai un numero di chiavi private nella tua directory .ssh puoi disabilitare "Autenticazione con chiave pubblica" dalla riga di comando usando l'argomento opzionale '-o'.

Per esempio:

$ ssh -o PubkeyAuthentication=no root@host

Se si dispone di una password e si desidera semplicemente utilizzare la password per accedere, ecco come farlo.

Per usare SOLO l'autenticazione con password e NON usare la chiave pubblica e NON usare la "tastiera interattiva" in qualche modo fuorviante (che è un superset che include la password), puoi farlo dalla riga di comando:

ssh -o PreferredAuthentications=password user@example.com

Spegnendo @David dicendo, basta aggiungere questo IdentitiesOnly yes al tuo .ssh / config, fa la stessa cosa dissh -o PubkeyAuthentication=no.

Dopo aver effettuato l'accesso, rimuovi .ssh/authorized_keys. Ora, torna al computer locale e digita quanto segue

cat ~/.ssh/id_rsa.pub | ssh -o PubkeyAuthentication=no user@IP_ADDR 'cat >> .ssh/authorized_keys'. Questo dovrebbe riattivare il tuo ssh con chiave pubblica

So che questo è un vecchio thread, ma volevo solo aggiungere qui che mi ero imbattuto nello stesso messaggio di errore, ma era causato dal fatto che il proprietario della cartella .ssh era root anziché l'utente che stava usando la chiave. Ho corretto il problema eseguendo i seguenti comandi:

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

Mi sono anche assicurato che le autorizzazioni fossero corrette nella cartella .ssh:

sudo chmod 700 /home/user/.ssh

I file all'interno della directory .ssh dovrebbero avere l'autorizzazione di 600:

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

Nel mio caso, il problema erano le autorizzazioni di directory. Questo mi ha risolto:

$ chmod 750 ~;chmod 700 ~/.ssh

Nel mio caso, stava accadendo perché stavo usando il nome utente "ubuntu", ma il nome utente in questa istanza era "ec2-user"

Dopo aver fatto ciò che "John T" ha suggerito, ho ricevuto questo errore:

Autorizzazione negata (chiave pubblica).

Quindi ho trovato la soluzione (ovvero cambiando il nome utente in "ec2-user") in questa risposta: https://stackoverflow.com/questions/1454629/aws-ssh-access-permission-denied-publickey-issue

Ho avuto la mia chiave pubblica .ssh/authorized_keys2, ma il server è stato configurato per la sola lettura .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

Dopo aver spostato il mio file in .ssh/authorized_keys, posso accedere con successo con la mia chiave.

Troppi errori di autenticazione

Questo messaggio è causato da troppi tentativi di autenticazione falliti dati i limiti consentiti applicati sul server SSH remoto. Questo potenzialmente significa che hai troppe identità aggiunte nell'agente SSH.

Ecco alcuni suggerimenti:

• Aggiungi -vper vedere se è così (hai usato troppe identità).
• Elencare le identità aggiunte per ssh-add -l.
• Rimuovere mancanza di identità dall'agente da: ssh-add -d.
• È inoltre possibile eliminare tutte le identità ssh-add -De aggiungere di nuovo solo quella pertinente.

• Se hai accesso al server SSH, seleziona l' MaxAuthTriesopzione (vedi:) man sshd_config.

  ^{Articoli correlati: Che cos'è una connessione per sshd_configil limite di "MaxAuthTries"?}

• Se nessuno di questi aiuti, assicurati di utilizzare le credenziali o il file corretti.

Questo messaggio può apparire quando non si inseriscono nome utente e password corretti.

Per prima cosa controlla che l'utente sia elencato:

vim /etc/passwd