Lato client: ssh -v
ssh -v user@serverUna connessione attraversa delle fasi in un ordine fisso. Trova l'ultima fase che compare nell'output e sai dove sta il problema.
1. Lettura della configurazione
debug1: OpenSSH_10.3p1, LibreSSL 3.3.6
debug1: Reading configuration data /Users/you/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_configQui vedi la versione del client e i file di configurazione usati. Le righe che citano un blocco Host ti dicono quali hanno corrisposto.
2. Connessione
debug1: Connecting to server [203.0.113.10] port 22.
debug1: Connection established.Controlla che indirizzo e porta siano quelli che ti aspettavi. Se non arrivi mai a Connection established, il problema è la rete o il servizio, non il tuo login:
ssh: connect to host 203.0.113.10 port 22: Connection refusedVedi connection refused, connection timed out e could not resolve hostname.
3. Individuazione delle chiavi e incontro con il server
debug1: identity file /Users/you/.ssh/id_ed25519 type 2
debug1: Local version string SSH-2.0-OpenSSH_10.3
debug1: Remote protocol version 2.0, remote software version OpenSSH_10.0p2 Debian-7+deb13u4
debug1: Authenticating to server:22 as 'user'Controlla il nome utente nell'ultima riga. Un utente sbagliato passa facilmente inosservato ed è sufficiente a far fallire un login. identity file ... type -1 significa che quel file non è stato trovato, il che è normale per i tipi di chiave che non hai.
4. Accordo sugli algoritmi
debug1: kex: algorithm: mlkem768x25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: noneSe non c'è corrispondenza, si ferma qui con un messaggio Unable to negotiate. Vedi no matching key exchange.
5. Verifica dell'identità del server
debug1: Server host key: ssh-ed25519 SHA256:c+CTM4jkNvBP8UG87Uh12f2SwOsRapfKmGCO8Yv6tc4
debug1: Host 'server' is known and matches the ED25519 host key.
debug1: Found key in /Users/you/.ssh/known_hosts:1Se la chiave non corrisponde, si ferma qui. Vedi host key changed.
6. Il login
La maggior parte dei problemi sta qui. Così appare un fallimento:
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Will attempt key: /Users/you/.ssh/id_ed25519 ED25519 SHA256:5WGoVhFgmqkQ/7SmXA0cfMDG6u2weqiLGzzf+uY8hCg explicit
debug1: Offering public key: /Users/you/.ssh/id_ed25519 ED25519 SHA256:5WGoVhFgmqkQ/7SmXA0cfMDG6u2weqiLGzzf+uY8hCg explicit
debug1: Authentications that can continue: publickey,password
debug1: No more authentication methods to try.
user@server: Permission denied (publickey,password).E questo è un successo:
debug1: Offering public key: /Users/you/.ssh/id_ed25519 ED25519 SHA256:NxFS05Q+k1zf9LgrjGPL94UJfFS6B/89THkWACOEJgg explicit
debug1: Server accepts key: /Users/you/.ssh/id_ed25519 ED25519 SHA256:NxFS05Q+k1zf9LgrjGPL94UJfFS6B/89THkWACOEJgg explicit
Authenticated to server ([203.0.113.10]:22) using "publickey".| Cosa vedi | Cosa significa |
|---|---|
Nessuna riga Offering public key | Il client non ha trovato nessuna chiave da provare. Controlla il percorso, o usa -i. |
| Viene offerta una chiave diversa da quella voluta | Imposta IdentityFile e IdentitiesOnly yes per quell'host. |
Offering senza Server accepts key | Il server non ha accettato quella chiave. Il motivo è nel suo log. Vedi sotto. |
Server accepts key, poi un fallimento | Il server accetta la chiave, ma il client non ha potuto firmare, per esempio per una passphrase sbagliata. |
In Authentications that can continue manca quello che volevi | Il server ha disattivato quel metodo. |
Per le soluzioni vedi Permission denied (publickey).
7. Dopo il login
debug1: Entering interactive session.
debug1: Sending command: true
debug1: Exit status 0Se il login funziona e la sessione si chiude subito dopo, guarda la shell, i file di avvio o un comando forzato sul server, non SSH stesso.
-v, -vv e -vvv
Per un solo login fallito, il nostro test ha stampato 49 righe con -v, 95 con -vv e 133 con -vvv.
-vvaggiunge gli elenchi completi degli algoritmi offerti da ciascuna parte, sottolocal client KEXINIT proposalepeer server KEXINIT proposal. Usalo per i problemi di algoritmi.-vvvaggiunge dettagli di basso livello comedebug3: send packet: type 20. Aiuta di rado, a meno che tu stia segnalando un bug.
Per tenere l'output in un file, o vedere solo ciò che serve:
ssh -v -E debug.log user@server
ssh -v user@server 2>&1 | grep -E 'Connecting|Offering|accepts|Authenticat|denied'Vedere le impostazioni reali: ssh -G
ssh -G server | grep -E '^(user|hostname|port|identityfile|proxyjump) 'Stampa ciò che il client userebbe dopo aver letto tutta la sua configurazione, e non si collega. Chiude la maggior parte delle discussioni su quale blocco Host si applichi. Con questa configurazione:
Host web*
User deploy
Port 2200
HostName 203.0.113.10
Host *
User other
Port 22ssh -G web1 dà il risultato seguente, perché vince il primo valore trovato:
user deploy
hostname 203.0.113.10
port 2200Altri dettagli nella guida al file ssh config.
Provare senza terminale: ssh -T
-T non richiede un terminale. Aiuta a distinguere un problema del login da un problema della sessione:
ssh -T user@server 'tty; echo TERM=$TERM'not a tty
TERM=dumbI servizi che non danno una shell, come gli host Git, si provano normalmente così: ssh -T git@github.com.
Lato server
Per sicurezza, il client sente solo Permission denied. Il motivo va nel log del server, quindi leggi prima quello se hai un altro modo per entrare. Vedi come controllare i tentativi di login.
sshd -d su un'altra porta
Avvia un secondo server che gestisce una sola connessione, stampa tutto ed esce. Il tuo sshd normale continua a funzionare:
sudo /usr/sbin/sshd -d -p 2200Poi, dal tuo computer:
ssh -p 2200 user@serverUn firewall potrebbe dover consentire quella porta. Serve il percorso completo: senza, ottieni sshd requires execution with an absolute path. Ecco la parte importante dell'output quando authorized_keys aveva il modo sbagliato:
debug1: userauth-request for user user service ssh-connection method publickey [preauth]
debug1: trying public key file /home/user/.ssh/authorized_keys
Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys
Failed publickey for user from 203.0.113.10 port 60932 ssh2: ED25519 SHA256:NxFS05Q+k1zf9LgrjGPL94UJfFS6B/89THkWACOEJggE quando funziona:
debug1: trying public key file /home/user/.ssh/authorized_keys
debug1: /home/user/.ssh/authorized_keys:1: matching key found: ED25519 SHA256:NxFS05Q+k1zf9LgrjGPL94UJfFS6B/89THkWACOEJgg
Accepted key ED25519 SHA256:NxFS05Q+k1zf9LgrjGPL94UJfFS6B/89THkWACOEJgg found at /home/user/.ssh/authorized_keys:1Usa -dd o -ddd per avere di più. Fermalo con Ctrl+C se nessuno si collega. Se la tua connessione non compare mai in questo output, qualcosa davanti al server, come un firewall, la sta fermando.
sshd -T: le impostazioni in uso
sudo sshd -T | grep -iE '^(port|passwordauthentication|pubkeyauthentication|authorizedkeysfile|permitrootlogin|maxauthtries) 'Legge i file di configurazione come fa il server, compresi quelli inclusi, e stampa i risultati. Mostra le impostazioni così come le definiscono i file, quindi un server non ancora ricaricato può usare ancora valori più vecchi. Per vedere l'effetto dei blocchi Match, descrivi una connessione:
sudo sshd -T -C user=user,host=client.example.com,addr=203.0.113.10 | grep -i passwordauthenticationUsa sudo sshd -t per controllare solo la sintassi. Non stampa nulla se è tutto a posto.
Domande
È sicuro condividere l'output di ssh -v?
Non contiene le tue password né le chiavi private, ma mostra nomi utente, nomi host, indirizzi, percorsi delle chiavi e fingerprint. Rileggilo prima di pubblicarlo in un posto pubblico.
Devo usare sempre -vvv?
No. Parti da -v. Risponde alla maggior parte delle domande, e i livelli successivi aggiungono soprattutto dettagli del protocollo.