Configurare SSH su Ubuntu: Soluzioni a Errori Comuni

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

  1. Verificare che la chiave pubblica dell’utente si trovi in ~/.ssh/authorized_keys sul server.
  2. 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
    28
       chmod 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

  1. Assicurarsi che sshd sia attivo:
    1
    2
    3
    4
    5
    6
    7
    8
    9
       sudo 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

  1. Verificare la rete e la latenza con ping o traceroute.
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
       ping 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

  1. Impostare i permessi corretti:
    1
    2
    3
    4
    5
    6
       chmod 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

  1. Se si possiede una chiave nel formato .ppk, convertirla con puttygen:
    1
    2
    3
    4
    5
    6
       puttygen 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

  1. Modificare /etc/ssh/sshd_config:
    1
    2
    3
    4
    5
       PasswordAuthentication 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

  1. Rimuovere la vecchia chiave dal file known_hosts:
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
       ssh-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

  1. Controllare la connettività DNS:
    1
    2
    3
    4
    5
       nslookup 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

  1. Limitare le chiavi caricate nell’agente SSH:
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
       ssh-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.