SSH (Secure Shell) è uno strumento fondamentale per accedere in modo sicuro a un server remoto. In questa guida, condivido come ho configurato SSH su un server Ubuntu e come ho risolto alcuni errori che ho incontrato durante il processo.
Errori Riscontrati e Soluzioni
Ecco alcuni dei messaggi di errore che ritengo utili condividere durante la configurazione di SSH, insieme alle soluzioni applicate.
1. Autenticazione tramite chiave pubblica non funzionante
Messaggio di errore
| 1 | Permission denied (publickey) | 
Causa
Questo errore si verifica quando la chiave pubblica non è stata correttamente aggiunta al file authorized_keys sul server, oppure se i permessi dei file e delle directory coinvolte non sono conformi alle aspettative di sshd.
Soluzione
- Verificare che la chiave pubblica dell’utente si trovi in ~/.ssh/authorized_keyssul server.
- Controllare i permessi:  1 
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28chmod 700 ~/.ssh 
 chmod 600 ~/.ssh/authorized_keys
 ```
 3. Assicurarsi che la proprietà di `~/.ssh` e `~/.ssh/authorized_keys` sia correttamente assegnata all’utente interessato.
 **Nota di approfondimento**
 È buona norma non rendere il file `authorized_keys` scrivibile da altri utenti per motivi di sicurezza.
 # 2. Servizio ssh non avviabile a causa di chiavi host mancanti
 **Messaggio di errore**
 ```plaintext
 Could not load host key: /etc/ssh/ssh_host_rsa_key
 ```
 (e messaggi simili per altre chiavi host)
 **Causa**
 La mancanza delle chiavi host o la loro corruzione impediscono al demone `sshd` di avviarsi correttamente.
 **Soluzione**
 1. Rigenerare le chiavi host:
 ```bash
 sudo ssh-keygen -A
 ```
 2. Riavviare il servizio:
 ```bash
 sudo systemctl restart ssh
Nota di approfondimento
Le chiavi host identificano il server. Rigenerarle comporta che i client dovranno confermare nuovamente l’impronta del server.
3. Connessione rifiutata (Connection refused)
Messaggio di errore
| 1 | ssh: connect to host 192.168.1.10 port 22: Connection refused | 
Causa
Il servizio sshd non è in esecuzione, la porta 22 è bloccata da un firewall, o l’indirizzo IP non è corretto.
Soluzione
- Assicurarsi che sshdsia attivo:1 
 2
 3
 4
 5
 6
 7
 8
 9sudo systemctl status ssh 
 ```
 2. In caso di servizio non attivo, avviarlo:
 ```bash
 sudo systemctl start ssh
 ```
 3. Verificare firewall e regole ufw:
 ```bash
 sudo ufw allow 22
Nota di approfondimento
Verificare anche la correttezza dell’indirizzo IP del server e la configurazione di rete.
4. Timeout durante l’autenticazione
Messaggio di errore
| 1 | ssh: connect to host esempio.com port 22: Operation timed out | 
Causa
Il server potrebbe essere raggiungibile ma lento a rispondere, oppure ci sono problemi di rete. Potrebbe anche essere presente un MaxStartups troppo basso in /etc/ssh/sshd_config che limita le connessioni contemporanee.
Soluzione
- Verificare la rete e la latenza con pingotraceroute.1 
 2
 3
 4
 5
 6
 7
 8
 9
 10ping esempio.com 
 ```
 2. Aumentare `ClientAliveInterval` o `MaxStartups` in `/etc/ssh/sshd_config` se il problema è legato alla configurazione del server:
 ```plaintext
 # Esempio:
 MaxStartups 10:30:60
 ```
 3. Riavviare `sshd`:
 ```bash
 sudo systemctl restart ssh
Nota di approfondimento
In caso di server con molte connessioni simultanee, considerare l’ottimizzazione dei parametri in sshd_config.
5. Errore “Bad owner or permissions”
Messaggio di errore
| 1 | Bad owner or permissions on /home/utente/.ssh/config | 
Causa
Il file di configurazione SSH o le directory che lo contengono non hanno i permessi richiesti. SSH è molto rigido riguardo ai permessi di ~/.ssh e dei file in esso contenuti.
Soluzione
- Impostare i permessi corretti:  1 
 2
 3
 4
 5
 6chmod 700 ~/.ssh 
 chmod 600 ~/.ssh/config
 ```
 2. Assicurarsi che la directory `~/.ssh` e i file all’interno siano di proprietà dell’utente stesso:
 ```bash
 chown utente:utente ~/.ssh ~/.ssh/config
Nota di approfondimento
È fondamentale garantire che nessun altro utente possa scrivere in questi file per motivi di sicurezza.
6. Chiavi non leggibili da ssh-agent
Messaggio di errore
| 1 | Error loading key "id_rsa": invalid format | 
Causa
La chiave privata potrebbe essere corrotta, nel formato sbagliato o non essere stata convertita correttamente (ad esempio da PuTTY .ppk a OpenSSH).
Soluzione
- Se si possiede una chiave nel formato .ppk, convertirla conputtygen:1 
 2
 3
 4
 5
 6puttygen key.ppk -O private-openssh -o id_rsa 
 ```
 2. Assicurarsi che la chiave sia in formato OpenSSH.
 3. Impostare i permessi adeguati:
 ```bash
 chmod 600 id_rsa
Nota di approfondimento
L’uso di chiavi corrette e ben formattate è essenziale per garantire un accesso sicuro.
7. Password non accettata nonostante sia corretta
Messaggio di errore
| 1 | Permission denied, please try again. | 
Causa
Potrebbe essere disabilitato l’accesso via password in /etc/ssh/sshd_config con PasswordAuthentication no.
Soluzione
- Modificare /etc/ssh/sshd_config:1 
 2
 3
 4
 5PasswordAuthentication yes 
 ```
 2. Riavviare il servizio:
 ```bash
 sudo systemctl restart ssh
Nota di approfondimento
L’accesso via password non è il più sicuro. Si consiglia di utilizzare chiavi pubbliche e private quando possibile.
8. “Host key verification failed”
Messaggio di errore
| 1 | Host key verification failed. | 
Causa
La chiave host del server è cambiata rispetto a quella conosciuta nel file ~/.ssh/known_hosts. Questo accade quando il server viene riconfigurato o rigenerato, oppure in caso di attacco di tipo “man-in-the-middle” (se la modifica non era attesa).
Soluzione
- Rimuovere la vecchia chiave dal file known_hosts:1 
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13ssh-keygen -R hostname_del_server 
 ```
 2. Connettersi nuovamente al server per accettare la nuova chiave.
 **Nota di approfondimento**
 Se la modifica della chiave host non era prevista, indagare sulle cause per escludere intrusioni o alterazioni non autorizzate.
 # 9. Errore "Could not resolve hostname"
 **Messaggio di errore**
 ```plaintext
 ssh: Could not resolve hostname esempio.com: Name or service not known
Causa
Il nome host non è risolvibile. Potrebbe essere un problema con i DNS o con la configurazione di /etc/hosts.
Soluzione
- Controllare la connettività DNS:  1 
 2
 3
 4
 5nslookup esempio.com 
 ```
 2. Se non risolvibile tramite DNS, aggiungere l’IP al file `/etc/hosts`:
 ```plaintext
 192.168.1.10 esempio.com
Nota di approfondimento
In ambienti interni o test, l’aggiunta al file hosts è rapida ma non scalabile. L’uso di DNS interni o server DNS dedicati è preferibile.
10. Errore “Too many authentication failures”
Messaggio di errore
| 1 | Received disconnect from X.X.X.X: 2: Too many authentication failures for utente | 
Causa
Il client sta presentando troppe chiavi o tentativi di autenticazione falliti in rapida successione. Ciò può accadere se l’agente SSH ha molte chiavi caricate o se la configurazione non è ottimale.
Soluzione
- Limitare le chiavi caricate nell’agente SSH:  1 
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13ssh-add -D 
 ```
 per scaricare tutte le chiavi e poi aggiungere solo quella necessaria:
 ```bash
 ssh-add ~/.ssh/id_rsa
 ```
 2. Aumentare `MaxAuthTries` in `/etc/ssh/sshd_config` se strettamente necessario:
 ```plaintext
 MaxAuthTries 6
 ```
 3. Riavviare il servizio:
 ```bash
 sudo systemctl restart ssh
Nota di approfondimento
Mantenere un numero limitato di tentativi riduce il rischio di attacchi brute-force. Meglio ottimizzare la configurazione e l’agente SSH piuttosto che aumentare drasticamente il limite.
Conclusione
Configurare SSH su Ubuntu può presentare alcune sfide, ma spero che condividere la mia esperienza possa aiutare a risolvere problemi simili. Assicurarsi sempre di controllare i log di SSH in caso di problemi e di verificare eventuali file di configurazione aggiuntivi che potrebbero sovrascrivere le impostazioni principali.