Ragazzi, ho un problema che mi sta facendo impazzire con SSH su Ubuntu 22.04. Ho configurato una key pair RSA a 4096 bit, copiato la chiave pubblica sul server con ssh-copy-id, ma quando tento di connettermi ricevo sempre 'Permission denied (publickey)'. Ho già verificato:
- Permessi della cartella .ssh (700) e chiave privata (600)
- Impostazioni sshd_config: PubkeyAuthentication yes
- Riavviato il servizio sshd
- Controllato che l'utente remoto abbia la chiave in authorized_keys
Il comando che uso è semplice:
```bash
ssh -v -i ~/.ssh/id_rsa user@server
```
L'output di debug mostra:
```
debug1: Authentications that can continue: publickey
...
Received disconnect: 13: Permission denied
```
Cosa c'è che non vedo? Qualcuno con Ubuntu 24.04 ha avuto problemi simili? Sono certo di aver saltato qualcosa di stupido ma non capisco cosa. Se avete esperienze con autenticazione a chiave, illuminatevi.
Ok, qui c’è qualcosa che puzza più di un pesce lasciato al sole. Hai controllato i permessi, la configurazione, la chiave, ma hai verificato il contenuto di `authorized_keys`? Non dico di guardare solo i permessi, ma se per sbaglio la chiave pubblica è stata copiata male, tipo con un newline o spazi strani, SSH ti manda a quel paese senza pietà. Prova a fare un bel `cat ~/.ssh/authorized_keys` sul server e confrontalo con la tua chiave pubblica (quella che stai usando con `-i`).
Un altro classico: hai provato a connetterti col comando senza specificare `-i ~/.ssh/id_rsa`? Magari il client sta provando altre chiavi e quella specifica è ignorata o non caricata per qualche motivo.
E poi, trova il file di log di sshd sul server (`/var/log/auth.log` o simili) e ficca lì il naso, perché il client dice “permission denied” ma il server spesso ti spara info più precise.
Ah, e non usare RSA a 4096 bit come se fosse la panacea, a volte OpenSSH preferisce chiavi ed25519 moderne. Cambia e vedi che succede, magari la tua chiave è ritenuta “obsoleta” o qualcosa del genere.
Insomma, non è un mistero da risolvere con la magia, controlla con metodo e soprattutto leggi i log sul server.
Eh, che rompicapo! Capisco la frustrazione, visto che SSH mi serve spesso per gestire server mentre sono in giro tra trekking. Hai già fatto controlli solidi, ma due cose mi salgono alla mente:
1. **Log del server**: Sbircia in `/var/log/auth.log` sul server. Spesso lì trovi errori nascosti tipo "user key: bad permissions" o "key parse error" che il client non mostra. Una volta mi è successo per una riga vuota in `authorized_keys`, risolto con `vim -b` per vedere i caratteri nascosti.
2. **Agent SSH in conflitto**: Prova `ssh-add -l` per vedere se altre chiavi caricate stanno "rubando" la connessione. Se ne trovi, svuota con `ssh-add -D` e tenta di nuovo. Oppure forza il percorso esatto con `ssh -o IdentitiesOnly=yes -i /percorso/chiave user@server`.
Per il futuro, cambia a chiavi ed25519: più veloci e sicure. Vedi se funziona generandone una nuova (`ssh-keygen -t ed25519`). Se il problema persiste, butta un occhio a SELinux/AppArmor sul server che potrebbe bloccare l'accesso alla cartella `.ssh`... e fammi sapere!
Grazie @danagatti, suggerimenti preziosissimi. Ho controllato `/var/log/auth.log` e SORPRESA: c'era un errore `key parse error`! Usato `vim -b` e scoperto un carattere invisibile maledetto in `authorized_keys` rimosso.
Ho anche eseguito `ssh-add -D` per pulire l'agente, ma il colpevole era proprio quel byte fantasma.
Per sicurezza, ho generato una chiave ed25519 (`ssh-keygen -t ed25519`) e ora tutto funziona. SELinux era disattivato, ma il tuo consiglio sui log è stato salvifico.
Grandioso! Capisco benissimo la tua frustrazione: quei caratteri invisibili in authorized_keys sono una rogna, soprattutto quando li becchi dopo ore di controlli. Ho visto casi simili con chiavi copiate da Mac, dove gli spazi o i charset strani si intrufolano come un brutto raffreddore in vacanza. Ed25519 è la scelta giusta, pulita e moderna – RSA 4096 oggi è come usare un carro armato per aprire un barattolo di marmellata.
Però non abbassare la guardia: AppArmor o systemd-logind potrebbero ancora creare casini se i permessi delle home sono strani (sì, mi è capitato su un server dopo un aggiornamento di Ubuntu). E la prossima volta, prova a usare `ssh-copy-id` con parsimonia, ma solo dopo aver controllato la chiave con `cat -A` o `hexdump`.
Ora che hai risolto, fatti un caffè e ringrazia @danagatti. E se SELinux era spento, forse era il caso di lasciarlo in pace… ma i log server sono sempre il tuo migliore amico, mai fidarsi del client!