Risoluzione degli errori comuni 'Permesso negato' e problemi di connessione SSH

Un errore SSH Permesso negato di solito significa che il server era raggiungibile, ma ha rifiutato di autenticarti. Questo è diverso da Connessione scaduta, Connessione rifiutata o Nessuna rotta verso l'host. Trattare tutti questi come "SSH è rotto" spreca tempo, quindi inizia separando i fallimenti di autenticazione dai fallimenti di rete.

Esegui il comando che fallisce con registrazione verbosa:

ssh -vvv utente@host_remoto

Stai cercando indizi chiari: quale nome utente ha usato il client, quali file di chiave ha offerto, se il server ha accettato qualche chiave e quali metodi di autenticazione rimangono. La maggior parte delle correzioni di seguito deriva dal confronto di questi indizi con lo stato lato server.

Comprensione del flusso di autenticazione SSH

Quando tenti di connetterti, il server consente solo i metodi di autenticazione abilitati nella sua configurazione. Un server tipico prova prima l'autenticazione con chiave pubblica e può consentire l'autenticazione con password dopo, a seconda della policy:

Autenticazione con chiave pubblica: Il client presenta una chiave pubblica e il server verifica se la corrispondente chiave privata è valida e corrisponde a una chiave autorizzata (file authorized_keys).
Autenticazione con password: Se l'autenticazione con chiave fallisce o è disabilitata, il server richiede una password.

Quando ricevi Permesso negato, la connessione TCP ha funzionato. Il server semplicemente non ha accettato la credenziale che hai presentato per quell'utente.

Diagnosi dei problemi di connessione: Il potere della modalità verbosa

Lo strumento singolo più efficace per diagnosticare i problemi SSH è eseguire il client in modalità verbosa. Aggiungendo i flag -v, -vv o -vvv, il client produce informazioni di debug dettagliate sul processo di negoziazione.

Utilizzo dei flag verbosi

Usa la seguente struttura di comando:

ssh -vvv utente@host_remoto

Cosa cercare nell'output:

Nome utente: Cerca Autenticazione in corso come 'utente'. Un nome utente Linux sbagliato è uno degli errori più facili da trascurare.
Chiavi offerte: Cerca Offerta chiave pubblica. Se la chiave prevista non appare mai, correggi la configurazione del client.
Risposta del server: Se ogni chiave offerta è seguita da Autenticazioni che possono continuare, il server ha rifiutato quelle chiavi.
Metodi di autenticazione: Se publickey non è elencato, il server potrebbe non consentire l'autenticazione con chiave per quell'account o blocco host.

Risoluzione di `Permesso negato (publickey)`

Questo errore afferma esplicitamente che il server ha rifiutato la credenziale di chiave pubblica fornita. La correzione di solito risiede nelle autorizzazioni o nell'abbinamento delle chiavi.

1. Controlla le autorizzazioni del file di chiave (lato client)

Per motivi di sicurezza, i client SSH sono molto severi riguardo alle autorizzazioni sul tuo file di chiave privata (ad es., ~/.ssh/id_rsa). Se questi file sono troppo aperti, il client si rifiuterà di usarli.

Assicurati che la tua chiave privata sia leggibile solo da te:

chmod 600 ~/.ssh/id_rsa

2. Verifica l'esistenza della chiave e l'uso corretto della chiave

Assicurati di connetterti con il file di identità corretto, specialmente se usi chiavi non standard o più coppie di chiavi.

Specifica la chiave privata corretta usando il flag -i:

ssh -i /percorso/della/tua/chiave_privata_specifica utente@host_remoto

Se il tuo agente ha molte chiavi caricate, aggiungi IdentitiesOnly=yes per questo test:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_prod utente@host_remoto

3. Autorizzazioni e proprietà lato server

Questa è la fonte più comune di fallimento dell'autenticazione con chiave. SSH impone autorizzazioni rigorose di directory e file sul server per l'utente con cui stai cercando di accedere.

Percorso sul server	Autorizzazioni richieste	Proprietario
Directory `~/.ssh`	`700` (rwx------)	Utente
File `~/.ssh/authorized_keys`	`600` (rw-------)	Utente

Accedi tramite console, console seriale cloud, autenticazione con password o un altro account amministratore ed esegui questi comandi come utente target o con il percorso corretto:

# Imposta le autorizzazioni della directory
chmod 700 ~/.ssh

# Imposta le autorizzazioni di authorized_keys
chmod 600 ~/.ssh/authorized_keys

# Verifica la proprietà (sostituisci 'miouser' con il nome utente effettivo)
chown -R miouser:miouser ~/.ssh

Se la directory home dell'utente è scrivibile dal gruppo o da altri, OpenSSH potrebbe anche rifiutare la chiave quando StrictModes è abilitato. Controlla con:

ls -ld ~ ~/.ssh ~/.ssh/authorized_keys

Per la maggior parte delle home utente normali, 755 o più restrittivo va bene.

4. Conferma che la chiave sia effettivamente aggiunta

Assicurati che la chiave pubblica sul client corrisponda a quella incollata nel file ~/.ssh/authorized_keys del server. Un carattere mancante, una riga spezzata o una chiave privata copiata causeranno un fallimento dell'autenticazione.

Quando aggiungi una chiave, usa ssh-copy-id se l'accesso con password è ancora disponibile:

ssh-copy-id utente@host_remoto

Risoluzione dei problemi del file di configurazione (`sshd_config`)

Se le chiavi e le autorizzazioni sono corrette, il problema spesso risiede nel file di configurazione del demone SSH, tipicamente situato in /etc/ssh/sshd_config sul server.

1. Controlla i metodi di autenticazione

Assicurati che l'autenticazione con chiave pubblica sia esplicitamente consentita.

Controllo della configurazione: Cerca le seguenti righe e assicurati che non siano commentate (#) e impostate correttamente:

PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

Controlla anche i blocchi Match vicino alla fine del file. Un'impostazione globale può consentire le chiavi pubbliche, mentre un successivo blocco Match User, Match Group o Match Address le disabilita per l'esatto login che stai testando.

2. Stato dell'autenticazione con password

Se ti stai affidando temporaneamente al login con password, verifica che sia abilitato. Se è impostato su no, devi necessariamente usare le chiavi.

PasswordAuthentication yes

3. PermitRootLogin

Se stai tentando di accedere come root, assicurati che sia permesso. La best practice è generalmente accedere come utente standard e usare sudo, ma per la risoluzione dei problemi, puoi controllare questa impostazione:

PermitRootLogin prohibit-password

Per il login di root, molti sistemi prevedono di default l'accesso root solo con chiave o disabilitano completamente il login di root. Preferisci un utente normale con sudo. Se devi modificare le impostazioni del demone SSH, convalida la sintassi prima di ricaricare:

sudo sshd -t
sudo systemctl reload sshd  # Alcuni sistemi usano: sudo systemctl reload ssh

Altri errori di connessione comuni

Mentre i problemi di chiave sono primari, altri errori possono bloccare l'accesso:

A. Connessione scaduta

Questo di solito significa che il client non ha potuto raggiungere affatto il server, indicando un problema di rete, non un problema di autenticazione.

Cause possibili:

Il server è spento o irraggiungibile.
Un firewall (locale o di rete) sta bloccando la connessione sulla porta 22 (o porta SSH personalizzata).
Indirizzo IP o nome host errato.

Usa ping per un suggerimento di base sulla raggiungibilità e nc per controllare la porta SSH:

nc -vz host_remoto 22

B. Nessuna rotta verso l'host

Simile al timeout, questo è un problema dell'infrastruttura di rete. Il client non riesce a trovare un percorso verso l'indirizzo IP del server. Controlla le tabelle di routing, lo stato della VPN o assicurati che il server remoto abbia un'interfaccia di rete valida attiva.

C. Il server ha rifiutato la nostra chiave

Se l'output verboso mostra che il server sta rifiutando attivamente le chiavi ma hai verificato il file authorized_keys, controlla i contesti di sicurezza SELinux o AppArmor sul server. Questi moduli di sicurezza possono sovrascrivere le autorizzazioni dei file e bloccare l'accesso SSH se i contesti non sono corretti.

Un ordine pratico che di solito funziona

Controlla prima il nome utente. Poi forza la chiave che ti aspetti con ssh -o IdentitiesOnly=yes -i .... Se il client offre la chiave giusta e il server la rifiuta, ispeziona authorized_keys, la proprietà e le autorizzazioni sul server. Se la chiave non viene mai offerta, correggi il tuo ~/.ssh/config locale, l'agente o il percorso della chiave. Se la connessione non raggiunge mai l'autenticazione, passa alla risoluzione dei problemi di rete invece di modificare i file di chiave.