sviluppo-web-qa.it

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 si tenta di 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 a PuTTY? Il riavvio di sshd sembra non aiutare

70
user11722

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.

8
damorg

"Troppi errori di autenticazione per l'utente root" significa che il tuo server SSH è limite MaxAuthTries superato. 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 Host/IdentityFile coppia in / home/USER/.ssh/config.
    • Host host
    • IdentityFile /home/USER/.ssh/id_rsa
    • Host host2
    • IdentityFile /home/USER/.ssh/id_rsa2
  3. Aumenta MaxAuthTries valore sul server SSH in / etc/ssh/sshd_config (non raccomandato).
128
Peta Sittek

Se viene visualizzato il seguente errore SSH:

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

Ciò potrebbe accadere se hai (per impostazione predefinita sul mio sistema) cinque o più file di identità DSA/RSA memorizzati nel tuo .ssh directory. In questo caso se il -i L'opzione non è specificata nella riga di comando per cui il client ssh tenterà prima di accedere utilizzando ciascuna identità (chiave privata) e successivamente Richiedi 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 potresti disabilitare Public Key Authentication dalla riga di comando usando -o argomento facoltativo.

Per esempio:

$ ssh -o PubkeyAuthentication=no [email protected]
98
Will Verna

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 alla macchina remota 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.

17
user59664

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 nel mio ~/.ssh cartella, come circa 16. E senza entrambe le direttive IdentityFile AND IdentitiesOnly nella configurazione, la mia macchina apparentemente stava provando tutte le chiavi in ​​~/.ssh e raggiungere il numero massimo di tentativi prima di tentare il file Identity corretto.

15
Ninjaxor

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.

12
Anonymous

Ho anche affrontato lo stesso problema. Questo può accadere facilmente se stai usando Pageant e hai un 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 è tratto da qui .)

6

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

Assicurati anche di abilitare PermitRootLogin in /etc/ssh/sshd_config file sul server.

6
Rodent43

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

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

Quindi provare ssh nella macchina remota

5
Sunil shakya

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>
3
andyfeller

Sono stato morso da un problema simile. Tuttavia la vera causa era che avevo ForwardAgent yes nel file di configurazione di una macchina lungo la pipe. 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.

2
Igor Stoppa

Ho risolto questo problema sul mio Mac:

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

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 consentire nuovamente l'accesso a 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 provare questo 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.

0
Sufferer

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 -

999.99.99.99:5901

Fatto !!

0
Rajnesh Thakur

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

Ho un vagabondo standard VM con una chiave SSH e posso SSH in esso usando PuTTY. Durante il tentativo di accedervi durante la distribuzione in PHPStorm ottengo l'errore too many authentication failures. Quindi aumentato il MaxAuthTries nel mio sshd_config e poi sono stato colpito con l'errore Auth failed 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 file .ppk Non funziona, quindi immagino sia un po 'magico;) Oh, e potrei sbarazzarmi dei MaxAuthTries dopo quel "punto trucco".

0
Adam Witorean

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

Se la tua distribuzione include fail2ban, che protegge i servizi che aggiungono 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 a.b.c.d:

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

Se hai DenyHosts, l'elenco bannato si trova nel file /etc/hosts.deny; puoi modificare questo file direttamente come root. Per concedere un accesso permanente IP a.b.c.d, è possibile aggiungere la riga sshd:a.b.c.d nel file /etc/hosts.allow.

Come sempre, il comando man è 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 viene superato il numero consentito, l'utente/attaccante si riconnette semplicemente per provare n volte di più.

Altri servizi avevano l'elenco dei divieti integrato (come mostrato nella risposta di Rajnesh Thakur sul riavvio del server VNC).

0
Fjor