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.