Come recuperare da "Troppi errori di autenticazione per l'utente root"

Ho fatto diversi tentativi per stabilire la connessione SSH per l'utente root @ host utilizzando il terminale putty. Nel fare ciò ho specificato più volte credenziali errate e successivamente le ho specificate correttamente, quindi dopo che le credenziali sono state accettate la sessione ssh si interrompe con

"Il server ha inaspettatamente chiuso la connessione di rete".

Questo errore è segnalato dal terminale putty. Quando provi a ssh root @ localhost dalla console locale - funziona benissimo. Funziona anche bene quando ssh altrouser @ host da un altro host. Quindi i problemi di connettività di rete non sono colpevoli. L'unico errore a cui sto pensando è: "Troppi errori di autenticazione per l'utente root" sebbene Putty abbia riportato un errore diverso.

La domanda è: come recuperare da questa condizione di errore e consentire nuovamente l'accesso al mastice? Il riavvio di sshd sembra non aiutare

Sei sicuro che sia consentito l'accesso root a ssh?

Controllare sshd_config e verificare che sia consentito l'accesso root. sshd dovrà essere riavviato se l'impostazione cambia.

"Troppi errori di autenticazione per l'utente root" significa che è stato superato il limite MaxAuthTries del server SSH . Succede in modo che il tuo client stia tentando di autenticarsi con tutte le possibili chiavi archiviate in /home/USER/.ssh/.

Questa situazione può essere risolta in questi modi:

1. ssh -i / path / to / id_rsa root @ host
2. Specificare la coppia Host / IdentityFile in /home/USER/.ssh/config .
   • Host host
   • IdentityFile /home/USER/.ssh/id_rsa
   • Host host2
   • IdentityFile /home/USER/.ssh/id_rsa2
3. Aumenta il valore MaxAuthTries sul server SSH in / etc / ssh / sshd_config (non raccomandato).

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 .sshdirectory. In questo caso se l' -iopzione non è specificata nella riga di comando, il client ssh tenterà prima di accedere utilizzando ciascuna identità (chiave privata) e il prossimo prompt per l'autenticazione della password. Tuttavia, sshd interrompe la connessione dopo cinque tentativi di accesso errati (di nuovo il valore predefinito può variare).

Quindi, se hai un numero di chiavi private nella tua directory .ssh, puoi disabilitare Public Key Authenticationdalla riga di comando usando l' -oargomento opzionale.

Per esempio:

$ ssh -o PubkeyAuthentication=no root@host

Sulla macchina remota aprire / etc / sshd_config e modificare il valore

MaxAuthTries 30

Questo è un problema tipico quando sono state installate più chiavi o si aprono più connessioni. Il server controlla passo dopo passo ogni tasto e se MaxAuthTries è impostato su 3, dopo i primi 3 tentativi si disconnetterà. Tipica sicurezza ssh.

Ti suggerisco di utilizzare la modalità dettagliata durante la connessione al computer remoto per analizzare il problema.

ssh -v -p numero_porta utente @ nomeserver

Indovinare come fanno la maggior parte delle persone su questo forum è SBAGLIATO e sta perdendo tempo. Prima prova ad analizzare il problema, raccogli informazioni e poi chiedi.

Divertiti.

Questa è una cattiva pratica. Basta avere un utente normale sulla casella remota e connettersi tramite ssh utilizzandolo, quindi ottenere l'accesso come root usando su / sudo.

Per me questo problema è stato risolto creando il seguente ssh_config per l'host a cui mi stavo connettendo.

(~ / .Ssh / config)

Host example
HostName example.com
User admin
IdentityFile ~/path/to/ssh_key_rsa
IdentitiesOnly=yes

Il problema si è verificato perché ho troppe chiavi ssh nella mia ~/.sshcartella, come 16 o giù di lì. E senza entrambe quelle IdentityFileE IdentitiesOnlydirettive nella configurazione, la mia macchina apparentemente stava provando tutte le chiavi ~/.sshe raggiungendo il numero massimo di tentativi prima di tentare il file Identity corretto.

Ti consiglierei, come ha scritto Anon sopra, di usare un altro utente per ottenere l'accesso ssh, quindi utilizzare il sucomando per ottenere l' rootaccesso.

Assicurati anche di abilitare PermitRootLoginnel /etc/ssh/sshd_configfile sul server.

Ho anche affrontato lo stesso problema. Questo può accadere facilmente se stai usando Pageant e hai un gran numero di chiavi caricate al suo interno , poiché questi server contano ogni offerta di una chiave pubblica come tentativo di autenticazione.

(Questo consiglio è preso da qui .)

Ho risolto questo problema nei miei sistemi eseguendo i seguenti comandi:

eval $(ssh-agent)
ssh-add  ~/.ssh/keyname

Quindi provare ssh nella macchina remota

Per risolvere temporaneamente questo problema fino a quando le cose non possono essere completamente risolte come indicato altrove, è possibile ripristinare il conteggio PAM di un utente in modo che possano riprovare:

pam_tally --reset --user <USERNAME>
pam_tally2 --reset --user <USERNAME>

Sono stato morso da un problema simile. Tuttavia, la vera causa era che avevo ForwardAgent yesnel file di configurazione di una macchina lungo la pipa. Stavo collegando dalla macchina A alla macchina B nella macchina C.

Il messaggio di errore è stato mostrato nel tentativo ssh da B -> C, ma è stato causato da A con l'inoltro attivo. Quindi a C furono inizialmente servite tutte le chiavi di A, e solo allora quelle di B.

Apparve all'improvviso quando ho aggiunto un'altra chiave ad A.

Ho risolto questo problema sul mio Mac:

1. quindi impostare la password di root con "sudo passwd root"
2. modifica e salvataggio del file di configurazione ssh con "nano / etc / ssh_config" e
3. cambiando RSAAuthentication in "no" piuttosto che sì.

OK, quindi nel mio caso è stato piuttosto strano, eccolo qui ...

Ho una VM vagabonda standard con una chiave SSH e posso entrare in SSH usando Putty. Durante il tentativo di ottenerlo durante la distribuzione in PHPStorm ricevo un too many authentication failureserrore. Quindi ho aumentato il valore MaxAuthTriesnel mio sshd_confige poi sono stato colpito con Auth failederrori e poi Auth cancel.

Ora, non so esattamente perché l'ho provato, ma ... Ho aggiunto il punto alla fine del mio percorso della chiave SSH nella finestra di distribuzione in PHPStorm. Quindi è stato così:

C:\Users\Deadpool\\.ssh\chimichanga

e ora è così:

C:\Users\Deadpool\\.ssh\chimichanga.

E funziona ... Nella mia cartella ".ssh" ho più file:

chimichanga - copy of "id_rsa" from vagrant machine
chimichanga.ppk
chimichanga.pub

Non sono sicuro di cosa faccia quel punto fcuking ma l'uso del .ppkfile non funziona, quindi immagino sia un po 'magico;) Oh, e potrei liberarmi dei MaxAuthTries dopo quel "punto trucco".

Altre risposte indicano il modo migliore per connettersi come root e le implicazioni di sicurezza di ciò, ma la tua domanda esplicita era

come recuperare da questa condizione di errore e riaccedere putty?

Quando accenni all'ultima connessione, il server remoto ha interrotto la connessione.

Quello che penso che potresti scoprire è che il server remoto sta eseguendo fail2ban (*) e ha "incarcerato" il tuo IP dopo il tuo login riuscito. Puoi provarlo provando ad accedere di nuovo e non otterrai nemmeno il prompt di accesso.

Ci sono due soluzioni, puoi aspettare il tempo di prigione, a quel punto le cose tornano semplicemente alla normalità, ma il tempo di prigione potrebbe essere qualsiasi cosa. Oppure puoi trovare computer diversi da cui accedere, farlo e "sbloccare" il tuo IP, in questo caso "diverso" è dal punto di vista del server remoto, quindi probabilmente un altro computer dietro lo stesso firewall probabilmente non funzionerà .

(*) fail2ban è un demone super pratico che può controllare periodicamente vari file di registro e regolare le regole del firewall per far "scomparire" il server quando rileva un comportamento potenzialmente dannoso da un client. Su debian, viene fuori dalla configurazione configurata per rilevare più accessi ssh non riusciti da un IP particolare, e dopo 3 (penso) lascerà cadere tutti i pacchetti da quell'IP. Funziona brillantemente per fermare quegli attacchi di forza bruta con script.

Come @sufferer ha menzionato in un'altra risposta, alcune distro Linux includono monitor per proteggere dagli attacchi di forza bruta su servizi visibili esterni come SSH, ad esempio DenyHostso fail2ban. Questi monitor controllano i file di registro alla ricerca di tentativi falliti e aggiungono filtri per bloccare gli indirizzi IP che presentano troppi errori (il numero è configurabile e indipendente dalla configurazione di sshd).

Se la tua distribuzione include fail2ban, che protegge i servizi aggiungendo regole al firewall iptables, puoi controllare quali servizi o "jail" sono supervisionati usando il comando:

sudo fail2ban-client status

Il jail per il servizio SSH è sshd, quindi per verificare se ci sono IP vietati puoi usare:

sudo fail2ban-client status sshd

e per sbloccare un po 'di IP abcd:

sudo fail2ban-client set sshd unbanip a.b.c.d

In tal caso DenyHosts, l'elenco vietato si trova nel file /etc/hosts.deny; puoi modificare questo file direttamente come root. Per concedere un accesso permanente ad abcd IP, è possibile aggiungere la linea sshd:a.b.c.dal file /etc/hosts.allow.

Come sempre, il mancomando è tuo amico:

man fail2ban
man hosts.deny

Dovrebbero esistere altre utilità simili, ma le ho utilizzate solo.

Si noti che l'aumento del numero di tentativi consentiti nella configurazione sshd non libera IP vietati, ma consente solo più errori nella stessa connessione. Se il numero consentito viene superato, l'utente / attaccante si riconnette semplicemente per provare n volte di più.

Ad altri servizi è stata integrata la lista dei divieti (come mostrato nella risposta di Rajnesh Thakur sul riavvio del server VNC).

Ho risolto questo problema con due semplici passaggi sul mio server Ubuntu 16.04 -

Per prima cosa fermare il mio server vnc o terminare il processo -

vncserver -kill :1

e poi ricominciare -

vncserver

Dopodiché connettilo dal client di Desktop remoto -

192.0.2.99:5901

Fatto !!

per la risoluzione, seguire i passaggi seguenti

1. Eseguire il backup / etc / ssh / sshd_config
2. Aumenta il valore di MaxAuthTries in sshd_config
3. stoprc -s sshd; startrc -s sshd

E ricontrolla dopo le modifiche sopra

Ho avuto lo stesso problema in cui continuavo a ricevere "SServer ha inviato il messaggio disconnesso di tipo 2 (errore di protocollo): troppi errori di autenticazione per l'utente"

Ho risolto questo problema rimuovendo tutti i miei ssh (chiavi .ppk) quindi ho effettuato l'accesso al server integrato AD.