Risolvere i problemi di accesso

Questa pagina fornisce suggerimenti per la risoluzione dei problemi di accesso a Bare Metal Solution.

Verifica se la tua domanda o il problema è già stato risolto nella pagina Problemi noti e limitazioni.

Impossibile connettere il client SSH

Se il client SSH non riesce a connettersi a un server, potresti visualizzare uno dei seguenti errori:

  • connection timeout o connection refused: il client SSH non è in grado di connettersi.

  • Permission denied (publickey): il client SSH non riesce a eseguire l'autenticazione.

Per diagnosticare le connessioni SSH non riuscite, procedi nel seguente modo:

  1. Testa la connettività.

    Assicurati che l'host sia raggiungibile e che la porta SSH (22) sia aperta utilizzando i comandi ping, traceroute e nc.

    ping SERVER_NAME
    
    traceroute SERVER_NAME
    
    echo "" | nc SERVER_NAME 22
    

    Se non funziona, il problema potrebbe riguardare il livello di rete e non SSH.

  2. Esamina l'output di debug lato client.

    1. Attiva le Preferenze di lettura del protocollo SSH.

      ssh -v SERVER_NAME -i ~/.ssh/id_ecdsa
      

      Il comando stampa l'output di debug che mostra gli eventi chiave del protocollo SSH lato client.

      L'output di esempio seguente mostra che il client ha inviato la chiave, ma il server l'ha rifiutata. Il server ha chiesto di continuare l'autenticazione con un'altra chiave pubblica, ma il client non ha chiavi aggiuntive da offrire.

      .. .. ..
      debug1: Server host key: ecdsa-sha2-nistp256 SHA256:V9cRYdqcAJv+RPfN+oofNTVdUxs6VlocP4uMWOxeGKI
      debug1: Host 'bms-server' is known and matches the ECDSA host key.
      debug1: Found key in /root/.ssh/known_hosts:1
      debug1: rekey after 134217728 blocks
      debug1: SSH2_MSG_NEWKEYS sent
      debug1: expecting SSH2_MSG_NEWKEYS
      debug1: SSH2_MSG_NEWKEYS received
      debug1: rekey after 134217728 blocks
      debug1: SSH2_MSG_EXT_INFO received
      debug1: kex_input_ext_info: server-sig-algs=
      debug1: SSH2_MSG_SERVICE_ACCEPT received
      debug1: Authentications that can continue: publickey
      debug1: Next authentication method: publickey
      debug1: Offering ECDSA public key: /root/.ssh/id_ecdsa
      debug1: Authentications that can continue: publickey
      debug1: No more authentication methods to try.
      Permission denied (publickey).
      
    2. Se l'output dettagliato di SSH non indica chiaramente la causa del messaggio di errore, esegui il comando strace:

      strace ssh SERVER_NAME -i ~/.ssh/id_ecdsa > strace-ssh.txt 2>&1
      
    3. Esamina l'output strace per individuare eventuali errori relativi al problema principale.

      In alcuni casi, l'output di debug lato client non è sufficiente per identificare il problema. Per trovare l'errore, potrebbe anche essere necessario eseguire il tracciamento lato server. Finché non riesci a connetterti al tuo server tramite SSH, utilizza la console seriale interattiva per eseguire i passaggi successivi.

  3. Esamina l'output di debug lato server.

    1. Trova le impostazioni SSH attuali.

      grep -v "^#" /etc/ssh/sshd_config | grep -v "^$"
      
    2. Per ottenere informazioni dettagliate su SSH, imposta i seguenti parametri nel file /etc/ssh/sshd_config.

      SyslogFacility AUTH
      LogLevel DEBUG
      
    3. Per applicare le modifiche, riavvia il servizio.

      service sshd restart
      
    4. Sul lato client, esegui il comando ssh ed estrai i messaggi sshd dai log:

      grep sshd /var/log/messages
      

      In alternativa, puoi esportare tutti i messaggi pertinenti per il periodo di tempo utilizzando il seguente comando:

      journalctl -u sshd -S "START_TIME" -U "END_TIME" --utc
      

      Sostituisci quanto segue:

      • START_TIME: l'ora di inizio del periodo di tempo nel formato yyyy-mm-dd hh:mm:ss.
      • END_TIME: l'ora di fine del periodo di tempo nel formato yyyy-mm-dd hh:mm:ss.

      Esempio:

      journalctl -u sshd -S "2023-04-25 18:38:00" -U "2023-04-25 18:40:00" --utc
      

Per risolvere questi problemi, prova a procedere nel seguente modo:

  • Verifica che il file delle chiavi client sia impostato con autorizzazioni di sola lettura (flag 400). In caso contrario, il client SSH non lo accetta.

    Per impostare il flag di sola lettura per la chiave privata in uso, esegui questo comando:

    chmod 400 ~/.ssh/id_ed25519
    
  • Sul lato server, controlla se la chiave pubblica del client è specificata nel file di configurazione locale dell'utente corrispondente (~/.ssh/authorized_keys).

  • In alcuni casi, il problema potrebbe essere legato alla versione del protocollo SSH o all'algoritmo SSH. Gli output di debug lato server e lato client potrebbero indicare questo problema. In genere, le pagine man per ssh e sshd_config forniscono i dettagli per mantenere la configurazione necessaria. Ad esempio, per trovare gli algoritmi di scambio di chiavi o le crittografie supportate, utilizza i seguenti comandi:

    # Find key exchange algorithms
    ssh -Q kex
    # Find the symmetric encryption ciphers
    ssh -Q cipher