Risolvere gli errori SSH

Linux Windows

---

Questo documento descrive gli errori comuni che potresti riscontrare durante la connessione alle istanze di macchine virtuali (VM) tramite SSH, i modi per risolvere gli errori e i metodi per diagnosticare le connessioni SSH non riuscite.

Strumento per la risoluzione dei problemi relativi a SSH

Utilizza lo strumento per la risoluzione dei problemi SSH per determinare il motivo per cui la connessione SSH non è riuscita. Lo strumento di risoluzione dei problemi esegue i seguenti test per verificare la causa delle connessioni SSH non riuscite:

• Test delle autorizzazioni utente:verifica se disponi delle autorizzazioni IAM necessarie per connetterti alla VM tramite SSH.
• Test di connettività di rete:controlla se la VM è connessa alla rete.
• Test dello stato dell'istanza VM:controlla lo stato della CPU della VM per vedere se la VM è in esecuzione.
• Test delle impostazioni VPC:controlla la porta SSH predefinita.

Esegui lo strumento per la risoluzione dei problemi

Puoi utilizzare la console Google Cloud o Google Cloud CLI per verificare la presenza di problemi di rete ed errori di autorizzazione utente che potrebbero causare il fallimento delle connessioni SSH.

Autorizzazioni richieste per questa attività

Per eseguire questa attività, devi disporre delle seguenti autorizzazioni:

• networkmanagement.connectivitytests.create sulla VM
• networkmanagement.connectivitytests.delete sulla VM
• networkmanagement.connectivitytests.get sulla VM

Se mancano una o più delle autorizzazioni precedenti, lo strumento di risoluzione dei problemi salta i test di connettività di rete.

Console

Dopo che una connessione SSH non è riuscita, puoi riprovare o risolvere i problemi utilizzando lo strumento per la risoluzione dei problemi SSH nel browser.

Per eseguire lo strumento di risoluzione dei problemi, fai clic su Risolvi i problemi.

gcloud

Esegui lo strumento per la risoluzione dei problemi utilizzando il comando gcloud compute ssh:

gcloud compute ssh VM_NAME \
    --troubleshoot

Sostituisci VM_NAME con il nome della VM a cui non riesci a connetterti.

Lo strumento ti chiede di autorizzarlo a eseguire i test di risoluzione dei problemi.

Esaminare i risultati

Dopo aver eseguito lo strumento di risoluzione dei problemi, procedi nel seguente modo:

1. Esamina i risultati del test per capire perché la connessione SSH della VM non funziona.
2. Risolvi le connessioni SSH eseguendo la procedura di correzione fornita dall' strumento.

3. Prova a riconnetterti alla VM.

   Se la connessione non va a buon fine, prova a risolvere il problema manualmente svolgendo quanto segue:

   • Risolvere i problemi di debug utilizzando la console seriale
   • Assicurati che la VM si avvii normalmente

Errori SSH comuni

Di seguito sono riportati alcuni esempi di errori comuni che potresti riscontrare quando utilizzi SSH per connetterti alle VM Compute Engine.

Errori SSH nel browser

Errore 401: accesso non autorizzato

Quando ti connetti alla VM utilizzando SSH nel browser dalla console Google Cloud, potrebbe verificarsi il seguente errore:

Unauthorized
Error 401

Questo errore si verifica se l'utente fa parte di un'organizzazione gestita da Google Workspace e nelle norme di Workspace è attiva una limitazione che impedisce agli utenti di accedere a SSH in-browser e alla console seriale in Google Cloud.

Per risolvere il problema, chiedi a un amministratore di Google Workspace di eseguire le seguenti operazioni:

1. Verifica che Google Cloud sia attivo per l'organizzazione.

   Se Google Cloud è disattivato, attivalo e riprova a effettuare la connessione.

2. Verifica che i servizi non controllabili singolarmente siano attivati.

   Se questi servizi sono disattivati, attivali e riprova a effettuare la connessione.

Se il problema persiste dopo aver attivato le impostazioni di Google Cloud in Google Workspace, segui questi passaggi:

1. Acquisisci il traffico di rete in un file HAR (HTTP Archive Format) a partire dall'avvio della connessione SSH in-browser.

2. Crea una richiesta all'Assistenza clienti Google Cloud e allega il file HAR.

Impossibile connettersi, nuovo tentativo in corso…

Quando avvii una sessione SSH, potrebbe verificarsi il seguente errore:

Could not connect, retrying ...

Per risolvere il problema:

1. Al termine dell'avvio della VM, riprova a effettuare la connessione. Se la connessione non va a buon fine, verifica che la VM non sia stata avviata in modalità di emergenza eseguendo il seguente comando:

   gcloud compute instances get-serial-port-output VM_NAME \
   | grep "emergency mode"
   

   Se la VM si avvia in modalità di emergenza, risolvi i problemi relativi alla procedura di avvio della VM per identificare il punto in cui si verifica l'errore.

2. Verifica che il servizio google-guest-agent.service sia in esecuzione eseguendo il seguente comando nella console seriale.

   systemctl status google-guest-agent.service
   

   Se il servizio è disattivato, attivalo e avvialo eseguendo i seguenti comandi:

   systemctl enable google-guest-agent.service
   systemctl start google-guest-agent.service
   

3. Verifica che gli script dell'agente Google per Linux siano installati ed eseguiti. Per ulteriori informazioni, consulta Determinare lo stato dell'agente Google. Se l'agente Google per Linux non è installato, reinstallalo.

4. Verifica di disporre dei ruoli necessari per connetterti alla VM. Se la VM utilizza OS Login, consulta Assegnare il ruolo IAM OS Login. Se la VM non utilizza OS Login, devi disporre del ruolo di amministratore dell'istanza Compute o del ruolo utente dell'account di servizio (se la VM è configurata per essere eseguita come account di servizio). I ruoli sono necessari per aggiornare i metadati delle chiavi SSH dell'istanza o del progetto.

5. Verifica che esista una regola firewall che consenta l'accesso SSH eseguendo il seguente comando:

   gcloud compute firewall-rules list | grep "tcp:22"
   

6. Verifica che esista una route predefinita per internet (o per l'host bastione). Per ulteriori informazioni, consulta la sezione Controllare i percorsi.

7. Assicurati che lo spazio su disco del volume principale non sia esaurito. Per ulteriori informazioni, consulta Risolvere i problemi relativi ai dischi con spazio esaurito e al ridimensionamento dei dischi.

8. Assicurati che la VM non abbia esaurito la memoria eseguendo il seguente comando:

   gcloud compute instances get-serial-port-output instance-name \
   | grep "Out of memory: Kill process" - e "Kill process" -e "Memory cgroup out of memory" -e "oom"
   

   Se la VM non dispone di memoria, connettiti alla console seriale per risolvere il problema.

Errori Linux

Autorizzazione negata (publickey)

Quando ti connetti alla VM, potrebbe verificarsi il seguente errore:

USERNAME@VM_EXTERNAL_IP: Permission denied (publickey).

Questo errore può verificarsi per diversi motivi. Di seguito sono riportate alcune delle cause più comuni di questo errore:

• Hai utilizzato una chiave SSH memorizzata nei metadati per connetterti a una VM su cui è attivato OS Login. Se nel progetto è abilitato l'accesso al sistema operativo, la VM non accetta le chiavi SSH memorizzate nei metadati. Se non sai con certezza se l'OS Login è attivo, consulta Verificare se l'OS Login è configurato.

  Per risolvere il problema, prova una delle seguenti soluzioni:

  • Connettiti alla VM utilizzando la console Google Cloud o Google Cloud CLI. Per maggiori informazioni, consulta la sezione Connessione alle VM.
  • Aggiungi le tue chiavi SSH a OS Login. Per ulteriori informazioni, consulta Aggiunta di chiavi alle VM che utilizzano OS Login.
  • Disattiva OS Login. Per ulteriori informazioni, consulta la pagina relativa alla disattivazione di OS Login.

• Hai utilizzato una chiave SSH memorizzata in un profilo OS Login per connetterti a una VM su cui non è abilitato OS Login. Se disattivi OS Login, la VM non accetta le chiavi SSH memorizzate nel tuo profilo OS Login. Se non sai con certezza se OS Login è abilitato, consulta Verificare se OS Login è configurato.

  Per risolvere il problema, prova una delle seguenti soluzioni:

  • Connettiti alla VM utilizzando la console Google Cloud o Google Cloud CLI. Per maggiori informazioni, consulta la sezione Connessione alle VM.
  • Attiva OS Login. Per ulteriori informazioni, consulta Attivare l'accesso al sistema operativo.
  • Aggiungi le tue chiavi SSH ai metadati. Per saperne di più, consulta Aggiungere chiavi SSH alle VM che utilizzano chiavi SSH basate su metadati.

• Nella VM è abilitato OS Login, ma non disponi di autorizzazioni IAM sufficienti per utilizzarlo. Per connetterti a una VM in cui è abilitato OS Login, devi disporre delle autorizzazioni necessarie per OS Login. Se non sai con certezza se l'OS Login è attivo, consulta Verificare se l'OS Login è configurato.

  Per risolvere il problema, concedi i ruoli IAM di accesso al sistema operativo richiesti.

• La tua chiave è scaduta e Compute Engine ha eliminato il tuo file ~/.ssh/authorized_keys. Se hai aggiunto manualmente le chiavi SSH alla VM e poi ti sei connesso alla VM utilizzando la console Google Cloud, Compute Engine ha creato una nuova coppia di chiavi per la connessione. Dopo la scadenza della nuova coppia di chiavi, Compute Engine ha eliminato il file ~/.ssh/authorized_keys nella VM, che includeva la chiave SSH aggiunta manualmente.

  Per risolvere il problema, prova una delle seguenti soluzioni:

  • Connettiti alla VM utilizzando la console Google Cloud o Google Cloud CLI. Per maggiori informazioni, consulta la sezione Connessione alle VM.
  • Aggiungi di nuovo la chiave SSH ai metadati. Per saperne di più, consulta Aggiungere chiavi SSH alle VM che utilizzano chiavi SSH basate su metadati.

• Hai eseguito la connessione utilizzando uno strumento di terze parti e il comando SSH è configurato in modo errato. Se esegui la connessione utilizzando il comando ssh, ma non specifichi un percorso per la chiave privata o ne specifichi uno errato, la VM rifiuta la connessione.

  Per risolvere il problema, prova una delle seguenti soluzioni:

  • Esegui questo comando:
    

    ssh -i PATH_TO_PRIVATE_KEY USERNAME@EXTERNAL_IP
    

    
    Sostituisci quanto segue:
    • PATH_TO_PRIVATE_KEY: il percorso del file della chiave SSH privata.
    • USERNAME: il nome utente dell'utente che si connette all'istanza. Se gestisci le chiavi SSH nei metadati, il nome utente è quello specificato quando hai creato la chiave SSH. Per gli account OS Login, il nome utente è definito nel tuo profilo Google.
    • EXTERNAL_IP: l'indirizzo IP esterno della VM.
  • Connettiti alla VM utilizzando la console Google Cloud o Google Cloud CLI. Quando utilizzi questi strumenti per la connessione, Compute Engine gestisce la creazione delle chiavi per te. Per ulteriori informazioni, consulta Connessione alle VM.

• L'ambiente guest della VM non è in esecuzione. Se è la prima volta che ti colleghi alla VM e l'ambiente guest non è in esecuzione, la VM potrebbe rifiutare la tua richiesta di connessione SSH.

  Per risolvere il problema:

  1. Riavvia la VM.
  2. Nella console Google Cloud, controlla i log di avvio del sistema nell'output della porta seriale per determinare se l'ambiente guest è in esecuzione. Per ulteriori informazioni, consulta la sezione Convalida dell'ambiente ospite.
  3. Se l'ambiente guest non è in esecuzione, installalo manualmente clonando il disco di avvio della VM e utilizzando uno script di avvio.

• Il demone OpenSSH (sshd) non è in esecuzione o non è configurato correttamente. sshd fornisce accesso remoto sicuro al sistema tramite il protocollo SSH. Se è configurato in modo errato o non è in esecuzione, non puoi connetterti alla VM tramite SSH.

  Nota: per risolvere il problema relativo a sshd, devi collegarti alla console seriale della VM come utente root.

  Per risolvere il problema, prova una o più delle seguenti operazioni:

  • Consulta la guida dell'utente del tuo sistema operativo per assicurarti che sshd_config sia configurato correttamente.

  • Assicurati di disporre delle impostazioni di proprietà e autorizzazione richieste per quanto segue:

    • Directory $HOME e $HOME/.ssh
    • File $HOME/.ssh/authorized_keys

    Proprietà

    L'ambiente guest memorizza le chiavi pubbliche SSH autorizzate nel $HOME/.ssh/authorized_keys file. Il proprietario delle directory $HOME e $HOME/.ssh e del file $HOME/.ssh/authorized_keys deve essere lo stesso dell' utente che si connette alla VM.

    Autorizzazioni

    L'ambiente guest richiede le seguenti autorizzazioni Linux:

    Percorso	Autorizzazioni
    /home	0755
    $HOME	0700 o 0750 o 0755 ^*
    $HOME/.ssh	0700
    $HOME/.ssh/authorized_keys	0600

    ^* Per scoprire quale delle opzioni è l'autorizzazione predefinita corretta per la tua directory $HOME, consulta la documentazione ufficiale della tua distribuzione Linux specifica.

    ---

    In alternativa, puoi creare una nuova VM basata sulla stessa immagine e controllare le autorizzazioni predefinite per $HOME.

    Per scoprire come modificare le autorizzazioni e la proprietà, leggi le informazioni su chmod e chown.

  • Riavviare sshd eseguendo il seguente comando:

    systemctl restart sshd.service

    Controlla se sono presenti errori nello stato eseguendo il seguente comando:

    systemctl status sshd.service

    L'output dello stato può contenere informazioni quali il codice di uscita, il motivo dell'errore e così via. Puoi utilizzare questi dettagli per ulteriori operazioni di risoluzione dei problemi.

• Il disco di avvio della VM è pieno. Quando viene stabilita una connessione SSH, l'ambiente guest aggiunge la chiave pubblica SSH della sessione al file ~/.ssh/authorized_keys. Se il disco è pieno, la connessione non riesce.

  Per risolvere il problema, esegui una o più delle seguenti operazioni:

  • Verifica che il disco di avvio sia pieno tramite il debug con la console seriale per identificare no space left errors.
  • Ridimensiona il disco.
  • Se sai quali file stanno utilizzando lo spazio su disco, crea uno script di avvio che elimini i file non necessari e libera spazio. Dopo l'avvio della VM e il collegamento a essa, elimina i metadati startup-script.

• Le autorizzazioni o la proprietà su $HOME, $HOME/.ssh o $HOME/.ssh/authorized_keys sono errate.

  Proprietà

  L'ambiente guest memorizza le chiavi pubbliche SSH autorizzate nel $HOME/.ssh/authorized_keys file. Il proprietario delle directory $HOME e $HOME/.ssh e del file $HOME/.ssh/authorized_keys deve essere lo stesso dell' utente che si connette alla VM.

  Autorizzazioni

  L'ambiente guest richiede le seguenti autorizzazioni Linux:

  Percorso	Autorizzazioni
  /home	0755
  $HOME	0700 o 0750 o 0755 ^*
  $HOME/.ssh	0700
  $HOME/.ssh/authorized_keys	0600

  ^* Per scoprire quale delle opzioni è l'autorizzazione predefinita corretta per la tua directory $HOME, consulta la documentazione ufficiale della tua distribuzione Linux specifica.

  ---

  In alternativa, puoi creare una nuova VM basata sulla stessa immagine e controllare le autorizzazioni predefinite per $HOME.

  Per scoprire come modificare le autorizzazioni e la proprietà, leggi le informazioni su chmod e chown.

Connessione non riuscita

Quando ti connetti alla VM dalla console Google Cloud, dall'gcloud CLI, da un bastion host o da un client locale, potrebbero verificarsi i seguenti errori:

• Nella console Google Cloud:

  Connection Failed
  
  We are unable to connect to the VM on port 22.
  

• Gcloud CLI:

  ERROR: (gcloud.compute.ssh) [/usr/bin/ssh] exited with return code [255].
  

• Un bastion host o un client locale:

  port 22: Connection timed out.
  

  port 22: Connection refused
  

Questi errori possono verificarsi per diversi motivi. Di seguito sono riportate alcune delle cause più comuni degli errori:

• La VM è in fase di avvio e sshd non è ancora in esecuzione. Non puoi collegarti a una VM prima che venga eseguita.

  Per risolvere il problema, attendi il termine dell'avvio della VM e riprova a collegarti.

• sshd è in esecuzione su una porta personalizzata. Se hai configurato sshd in modo che venga eseguito su una porta diversa dalla 22, non potrai connetterti alla VM.

  Per risolvere il problema, crea una regola firewall personalizzata che consenta il traffico tcp sulla porta su cui è in esecuzione sshd utilizzando il seguente comando:

  gcloud compute firewall-rules create FIREWALL_NAME \
    --allow tcp:PORT_NUMBER
  

  Per ulteriori informazioni sulla creazione di regole firewall personalizzate, consulta Creare regole firewall.

• La regola firewall SSH non è presente o non consente il traffico dall'IAP o dalla rete internet pubblica. Le connessioni SSH vengono rifiutate se le regole del firewall non consentono connessioni dal traffico in entrata IAP o TCP per l'intervallo IP 0.0.0.0/0.

  Per risolvere il problema, esegui una delle seguenti operazioni:

  • Se utilizzi Identity-Aware Proxy (IAP) per l'inoltro TCP, aggiorna la regola del firewall personalizzata in modo da accettare il traffico da IAP, quindi controlla le autorizzazioni IAM.

    1. Aggiorna la regola firewall personalizzata per consentire il traffico da 35.235.240.0/20, l'intervallo di indirizzi IP utilizzato da IAP per l'inoltro TCP. Per maggiori informazioni, consulta Creare una regola firewall.
    2. Concedi le autorizzazioni per utilizzare l'inoltro TCP di IAP, se non l'hai già fatto.

  • Se non utilizzi l'IAP, aggiorna la regola firewall personalizzata per consentire il traffico in entrata SSH.

    1. Aggiorna la regola firewall personalizzata per consentire le connessioni SSH in entrata alle VM.

• La connessione SSH non è riuscita dopo l'upgrade del kernel della VM. Una VM potrebbe subire un panico del kernel dopo un aggiornamento del kernel, diventando inaccessibile.

  Per risolvere il problema:

  1. Monta il disco su un'altra VM.
  2. Aggiorna il file grub.cfg per utilizzare la versione precedente del kernel.
  3. Collega il disco alla VM che non risponde.
  4. Verifica che lo stato della VM sia RUNNING utilizzando il comando gcloud compute instances describe.
  5. Reinstalla il kernel.
  6. Riavvia la VM.

  In alternativa, se hai creato uno snapshot del disco di avvio prima di eseguire l'upgrade della VM, utilizza lo snapshot per creare una VM.

• Il demone OpenSSH (sshd) non è in esecuzione o non è configurato correttamente. sshd fornisce accesso remoto sicuro al sistema tramite il protocollo SSH. Se è configurato in modo errato o non è in esecuzione, non puoi connetterti alla VM tramite SSH.

  Nota: per risolvere il problema relativo a sshd, devi collegarti alla console seriale della VM come utente root.

  Per risolvere il problema, prova una o più delle seguenti operazioni:

  • Consulta la guida dell'utente del tuo sistema operativo per assicurarti che sshd_config sia configurato correttamente.

  • Assicurati di disporre delle impostazioni di proprietà e autorizzazione richieste per quanto segue:

    • Directory $HOME e $HOME/.ssh
    • File $HOME/.ssh/authorized_keys

    Proprietà

    L'ambiente guest memorizza le chiavi pubbliche SSH autorizzate nel $HOME/.ssh/authorized_keys file. Il proprietario delle directory $HOME e $HOME/.ssh e del file $HOME/.ssh/authorized_keys deve essere lo stesso dell' utente che si connette alla VM.

    Autorizzazioni

    L'ambiente guest richiede le seguenti autorizzazioni Linux:

    Percorso	Autorizzazioni
    /home	0755
    $HOME	0700 o 0750 o 0755 ^*
    $HOME/.ssh	0700
    $HOME/.ssh/authorized_keys	0600

    ^* Per scoprire quale delle opzioni è l'autorizzazione predefinita corretta per la tua directory $HOME, consulta la documentazione ufficiale della tua distribuzione Linux specifica.

    ---

    In alternativa, puoi creare una nuova VM basata sulla stessa immagine e controllare le autorizzazioni predefinite per $HOME.

    Per scoprire come modificare le autorizzazioni e la proprietà, leggi le informazioni su chmod e chown.

  • Riavviare sshd eseguendo il seguente comando:

    systemctl restart sshd.service

    Controlla se sono presenti errori nello stato eseguendo il seguente comando:

    systemctl status sshd.service

    L'output dello stato può contenere informazioni quali il codice di uscita, il motivo dell'errore e così via. Puoi utilizzare questi dettagli per ulteriori operazioni di risoluzione dei problemi.

• La VM non si avvia e non riesci a connetterti tramite SSH o la console seriale. Se la VM non è accessibile, il sistema operativo potrebbe essere danneggiato. Se il disco di avvio non si avvia, puoi diagnosticare il problema. Se vuoi recuperare la VM danneggiata e recuperare i dati, consulta Recuperare una VM o un disco di avvio completo danneggiati.

• La VM si avvia in modalità di manutenzione. Quando si avvia in modalità di manutenzione, la VM non accetta connessioni SSH, ma puoi connetterti alla console seriale della VM e accedere come utente root.

  Per risolvere il problema:

  1. Se non hai impostato una password di root per la VM, utilizza un script di avvio dei metadati per eseguire il seguente comando durante l'avvio:

     echo "root:NEW_PASSWORD" | chpasswd

     Sostituisci NEW_PASSWORD con una password a tua scelta.

  2. Riavvia la VM.

  3. Connettiti alla console seriale della VM e accedi come utente root.

Errore imprevisto

Quando provi a connetterti a una VM Linux, potrebbe verificarsi il seguente errore:

Connection Failed
You cannot connect to the VM instance because of an unexpected error. Wait a few moments and then try again.

Questo problema può verificarsi per diversi motivi. Di seguito sono riportate alcune cause comuni dell'errore:

• Il demone OpenSSH (sshd) non è in esecuzione o non è configurato correttamente. sshd fornisce accesso remoto sicuro al sistema tramite il protocollo SSH. Se è configurato in modo errato o non è in esecuzione, non puoi connetterti alla VM tramite SSH.

  Nota: per risolvere il problema relativo a sshd, devi collegarti alla console seriale della VM come utente root.

  Per risolvere il problema, prova una o più delle seguenti operazioni:

  • Consulta la guida dell'utente del tuo sistema operativo per assicurarti che sshd_config sia configurato correttamente.

  • Assicurati di disporre delle impostazioni di proprietà e autorizzazione richieste per quanto segue:

    • Directory $HOME e $HOME/.ssh
    • File $HOME/.ssh/authorized_keys

    Proprietà

    L'ambiente guest memorizza le chiavi pubbliche SSH autorizzate nel $HOME/.ssh/authorized_keys file. Il proprietario delle directory $HOME e $HOME/.ssh e del file $HOME/.ssh/authorized_keys deve essere lo stesso dell' utente che si connette alla VM.

    Autorizzazioni

    L'ambiente guest richiede le seguenti autorizzazioni Linux:

    Percorso	Autorizzazioni
    /home	0755
    $HOME	0700 o 0750 o 0755 ^*
    $HOME/.ssh	0700
    $HOME/.ssh/authorized_keys	0600

    ^* Per scoprire quale delle opzioni è l'autorizzazione predefinita corretta per la tua directory $HOME, consulta la documentazione ufficiale della tua distribuzione Linux specifica.

    ---

    In alternativa, puoi creare una nuova VM basata sulla stessa immagine e controllare le autorizzazioni predefinite per $HOME.

    Per scoprire come modificare le autorizzazioni e la proprietà, leggi le informazioni su chmod e chown.

  • Riavviare sshd eseguendo il seguente comando:

    systemctl restart sshd.service

    Controlla se sono presenti errori nello stato eseguendo il seguente comando:

    systemctl status sshd.service

    L'output dello stato può contenere informazioni quali il codice di uscita, il motivo dell'errore e così via. Puoi utilizzare questi dettagli per ulteriori operazioni di risoluzione dei problemi.

• Problema sconosciuto del daemon SSH. Per diagnosticare un problema sconosciuto del demone SSH, controlla se sono presenti errori nei log della console seriale.

  A seconda dell'output dei log della console seriale, prova a recuperare la VM e a risolvere i problemi relativi al daemon SSH nel seguente modo:

  1. Collega il disco a un'altra VM Linux.
  2. Connettiti alla VM con il disco montato.
  3. Monta il disco all'interno del sistema operativo in una directory MOUNT_DIR all'interno della VM.
  4. Visualizza i log relativi a SSH, /var/log/secure o /var/log/auth.log per eventuali problemi/errori. Se noti problemi che puoi risolvere, prova a risolverli. In caso contrario, crea una richiesta di assistenza e allega i log.

  5. Smonta il disco dal sistema operativo utilizzando il comando umount:

     cd ~/
     umount /mnt
     

  6. Scollega il disco dalla VM.

  7. Collega il disco alla VM originale.

  8. Avvia la VM.

Impossibile connettersi al backend

Quando ti connetti alla VM dalla console Google Cloud o dallgcloud CLI, potrebbero verificarsi i seguenti errori:

• Nella console Google Cloud:

  -- Connection via Cloud Identity-Aware Proxy Failed
  
  -- Code: 4003
  
  -- Reason: failed to connect to backend
  

• Gcloud CLI:

  ERROR: (gcloud.compute.start-iap-tunnel) Error while connecting [4003: 'failed to connect to backend'].
  

Questi errori si verificano quando provi a utilizzare SSH per connetterti a una VM che non ha un indirizzo IP pubblico e per la quale non hai configurato Identity-Aware Proxy sulla porta 22.

Per risolvere il problema, crea una regola firewall sulla porta 22 che consenta il traffico in entrata da Identity-Aware Proxy.

La chiave dell'host non corrisponde

Quando ti connetti alla VM, potrebbe verificarsi il seguente errore:

Host key for server IP_ADDRESS does not match

Questo errore si verifica quando la chiave host nel file ~/.ssh/known_hosts non corrisponde alla chiave host della VM.

Per risolvere il problema, elimina la chiave host dal ~/.ssh/known_hosts file, quindi riprova a eseguire la connessione.

Il valore dei metadati è troppo grande

Quando provi ad aggiungere una nuova chiave SSH ai metadati, potrebbe verificarsi il seguente errore:

ERROR:"Value for field 'metadata.items[X].value' is too large: maximum size 262144 character(s); actual size NUMBER_OF_CHARACTERS."

I valori dei metadati hanno un limite massimo di 256 KB. Per ovviare a questo limite, esegui una delle seguenti operazioni:

• Elimina le chiavi SSH scadute o duplicate dai metadati del progetto o dell'istanza. Per ulteriori informazioni, consulta Aggiornare i metadati su una VM in esecuzione.
• Utilizza OS Login.

Errori di Windows

Anteprima - SSH for Windows

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Autorizzazione negata. Riprova

Quando ti connetti alla VM, potrebbe verificarsi il seguente errore:

[e-mail]_ID's password:
Permission denied, please try again.

Questo errore indica che l'utente che tenta di connettersi alla VM non esiste sulla VM. Di seguito sono riportate alcune delle cause più comuni di questo errore:

• La tua versione di gcloud CLI è obsoleta

  Se gcloud CLI non è aggiornata, potresti provare a connetterti utilizzando un nome utente non configurato. Per risolvere il problema, aggiorna la gcloud CLI.

• Hai provato a connetterti a una VM Windows su cui non è abilitato SSH.

  Per risolvere questo errore, imposta la chiave enable-windows-ssh su TRUE nei metadati del progetto o dell'istanza. Per ulteriori informazioni sull'impostazione dei metadati, consulta Impostare metadati personalizzati.

Autorizzazione negata (publickey,keyboard-interactive)

Quando ti connetti a una VM in cui non è attivato SSH, potrebbe verificarsi il seguente errore:

Permission denied (publickey,keyboard-interactive).

Per risolvere questo errore, imposta la chiave enable-windows-ssh su TRUE nei metadati del progetto o dell'istanza. Per ulteriori informazioni sull'impostazione dei metadati, consulta Impostare metadati personalizzati.

Impossibile accedere tramite SSH all'istanza

Quando ti connetti alla VM dallgcloud CLI, potrebbe verificarsi il seguente errore:

ERROR: (gcloud.compute.ssh) Could not SSH into the instance.
It is possible that your SSH key has not propagated to the instance yet.
Try running this command again.  If you still cannot connect, verify that the firewall and instance are set to accept ssh traffic.

Questo errore può verificarsi per diversi motivi. Di seguito sono riportate alcune delle cause più comuni degli errori:

• Hai provato a connetterti a una VM Windows su cui non è installato SSH.

  Per risolvere il problema, segui le istruzioni per abilitare SSH per Windows su una VM in esecuzione.

• Il server OpenSSH (sshd) non è in esecuzione o non è configurato correttamente. sshd fornisce accesso remoto sicuro al sistema tramite il protocollo SSH. Se è configurato in modo errato o non è in esecuzione, non puoi connetterti alla VM tramite SSH.

  Per risolvere il problema, consulta la configurazione del server OpenSSH per Windows Server e Windows per assicurarti che sshd sia configurato correttamente.

Timeout della connessione

Le connessioni SSH con timeout potrebbero essere causate da uno dei seguenti motivi:

• L'avvio della VM non è stato completato. Attendi qualche istante per l'avvio della VM.

  Per risolvere il problema, attendi il termine dell'avvio della VM e riprova a collegarti.

• Il pacchetto SSH non è installato. Le VM Windows richiedono l'installazione del pacchetto google-compute-engine-ssh prima di poter effettuare la connessione tramite SSH.

  Per risolvere il problema, installa il pacchetto SSH.

Diagnostica le connessioni SSH non riuscite

Le sezioni seguenti descrivono i passaggi che puoi svolgere per diagnosticare la causa delle connessioni SSH non riuscite e per correggere le connessioni.

Prima di diagnosticare le connessioni SSH non riuscite, completa i seguenti passaggi:

• Installa o esegui l'aggiornamento alla versione più recente di Google Cloud CLI.
• Esegui test di connettività.
• Se utilizzi un'immagine Linux personalizzata in cui non è in esecuzione l'ambiente guest, installa l'ambiente guest Linux.
• Se utilizzi OS Login, consulta la sezione Risoluzione dei problemi relativi a OS Login.

Metodi di diagnostica per le VM Linux e Windows

Testa la connettività

Potresti non riuscire a connetterti tramite SSH a un'istanza VM a causa di problemi di connettività legati a firewall, connessione di rete o account utente. Segui i passaggi in questa sezione per identificare eventuali problemi di connettività.

Controlla le regole del firewall

Compute Engine esegue il provisioning di ogni progetto con un insieme predefinito di regole firewall che consentono il traffico SSH. Se non riesci ad accedere all'istanza, utilizza lo strumento a riga di comando gcloud compute per controllare l'elenco dei firewall e assicurarti che la regola default-allow-ssh sia presente.

Nella workstation locale, esegui il seguente comando:

gcloud compute firewall-rules list

Se la regola firewall non è presente, aggiungila di nuovo:

gcloud compute firewall-rules create default-allow-ssh \
    --allow tcp:22

Per visualizzare tutti i dati associati alla regola firewall default-allow-ssh nel tuo progetto, utilizza il comando gcloud compute firewall-rules describe:

gcloud compute firewall-rules describe default-allow-ssh \
    --project=project-id

Per ulteriori informazioni sulle regole firewall, consulta Regole firewall in Google Cloud.

Verifica la connessione di rete

Per determinare se la connessione di rete funziona, testa l'handshake TCP:

1. Ottieni il natIP esterno per la tua VM:

   gcloud compute instances describe VM_NAME \
       --format='get(networkInterfaces[0].accessConfigs[0].natIP)'
   

   Sostituisci VM_NAME con il nome della VM a cui non riesci a collegarti.

   Nota: l'indirizzo IP può variare se utilizzi IAP per accedere all'istanza tramite l'indirizzo IP interno. Inoltre, se l'indirizzo IP è interno, l'istanza è accessibile solo dall'interno della rete VPC.

2. Testa la connessione di rete alla VM dalla workstation:

   Linux, Windows 2019/2022 e macOS

   curl -vso /dev/null --connect-timeout 5 EXTERNAL_IP:PORT_NUMBER
   

   Sostituisci quanto segue:

   • EXTERNAL_IP: l'indirizzo IP esterno ottenuto nel passaggio precedente
   • PORT_NUMBER: il numero di porta

   Se l'handshake TCP è riuscito, l'output è simile al seguente:

   Expire in 0 ms for 6 (transfer 0x558b3289ffb0)
   Expire in 5000 ms for 2 (transfer 0x558b3289ffb0)
   Trying 192.168.0.4...
   TCP_NODELAY set
   Expire in 200 ms for 4 (transfer 0x558b3289ffb0)
   Connected to 192.168.0.4 (192.168.0.4) port 443 (#0)
   > GET / HTTP/1.1
   > Host: 192.168.0.4:443
   > User-Agent: curl/7.64.0
   > Accept: */*
   >
   Empty reply from server
   Connection #0 to host 192.168.0.4 left intact
   

   La riga Connected to indica che l'handshake TCP è andato a buon fine.

   Windows 2012 e 2016

   PS C:> New-Object System.Net.Sockets.TcpClient('EXTERNAL_IP',PORT_NUMBER)
   

   Sostituisci quanto segue:

   • EXTERNAL_IP: l'IP esterno ottenuto nel passaggio precedente
   • PORT_NUMBER: il numero di porta

   Se l'handshake TCP è riuscito, l'output è simile al seguente:

   Available           : 0
   Client              : System.Net.Sockets.Socket
   Connected           : True
   ExclusiveAddressUse : False
   ReceiveBufferSize   : 131072
   SendBufferSize      : 131072
   ReceiveTimeout      : 0
   SendTimeout         : 0
   LingerState         : System.Net.Sockets.LingerOption
   NoDelay             : False
   

   La riga Connected: True indica che l'handshake TCP è andato a buon fine.

Se l'handshake TCP viene completato correttamente, una regola del firewall software non blocca la connessione, il sistema operativo inoltra correttamente i pacchetti e un server è in ascolto sulla porta di destinazione. Se la stretta di mano TCP viene completata correttamente, ma la VM non accetta connessioni SSH, il problema potrebbe essere che il daemon sshd non è configurato correttamente o non è in esecuzione correttamente. Consulta la guida dell'utente del tuo sistema operativo per assicurarti che sshd_config sia configurato correttamente.

Per eseguire test di connettività per analizzare la configurazione del percorso di rete VPC tra due VM e verificare se la configurazione programmata deve consentire il traffico, consulta Verificare la presenza di regole firewall configurate in modo errato in Google Cloud.

Connettiti come un altro utente

Il problema che ti impedisce di accedere potrebbe essere limitato al tuo account dell'utente. Ad esempio, le autorizzazioni per il file ~/.ssh/authorized_keys sull'istanza potrebbero non essere impostate correttamente per l'utente.

Prova ad accedere come altro utente con gcloud CLI specificando ANOTHER_USERNAME con la richiesta SSH. L'interfaccia a riga di comando gcloud aggiorna i metadati del progetto per aggiungere il nuovo utente e consentire l'accesso SSH.

gcloud compute ssh ANOTHER_USERNAME@VM_NAME

Sostituisci quanto segue:

• ANOTHER_USERNAME è un nome utente diverso dal tuo
• VM_NAME è il nome della VM a cui vuoi connetterti

Risolvere i problemi di debug utilizzando la console seriale

Ti consigliamo di esaminare i log della console seriale per verificare la presenza di errori di connessione. Puoi accedere alla console seriale come utente root dalla tua workstation locale utilizzando un browser. Questo approccio è utile quando non riesci a accedere con SSH o se l'istanza non ha connessione alla rete. La console seriale rimane accessibile in entrambe le situazioni.

Per accedere alla console seriale della VM e risolvere i problemi relativi alla VM, segui questi passaggi:

1. Abilita l'accesso interattivo alla console seriale della VM.

2. Per le VM Linux, modifica la password di root e aggiungi il seguente script di avvio alla VM:

   echo root:PASSWORD | chpasswd

   Sostituisci PASSWORD con una password a tua scelta.

3. Utilizza la console seriale per connetterti alla VM.

4. Per le VM Linux, dopo aver eseguito il debug di tutti gli errori, disattiva l'accesso all'account root:

   sudo passwd -l root

Metodi di diagnostica per le VM Linux

Controllare l'istanza VM senza arrestarla

Potresti avere un'istanza a cui non riesci a connetterti che continua a gestire correttamente il traffico di produzione. In questo caso, ti consigliamo di ispezionare il disco senza interrompere l'istanza.

Per ispezionare e risolvere i problemi relativi al disco:

1. Esegui il backup del disco di avvio creando uno snapshot del disco.
2. Crea un disco permanente normale da questo snapshot.
3. Crea un'istanza temporanea.
4. Collega e monta il disco permanente normale alla nuova istanza temporanea.

Questa procedura crea una rete isolata che consente solo connessioni SSH. Questa configurazione impedisce che l'istanza clonata interferisca con i servizi di produzione.

1. Crea una nuova rete VPC per ospitare l'istanza clonata:

   gcloud compute networks create debug-network
   

   Sostituisci NETWORK_NAME con il nome che vuoi assegnare alla nuova rete.

2. Aggiungi una regola firewall per consentire le connessioni SSH alla rete:

   gcloud compute firewall-rules create debug-network-allow-ssh \
      --network debug-network \
      --allow tcp:22
   

3. Crea uno snapshot del disco di avvio.

   gcloud compute disks snapshot BOOT_DISK_NAME \
      --snapshot-names debug-disk-snapshot
   

   Sostituisci BOOT_DISK_NAME con il nome del disco di avvio.

4. Crea un nuovo disco con lo snapshot appena creato:

   gcloud compute disks create example-disk-debugging \
      --source-snapshot debug-disk-snapshot
   

5. Crea una nuova istanza di debug senza un indirizzo IP esterno:

   gcloud compute instances create debugger \
      --network debug-network \
      --no-address
   

6. Collega il disco di debug all'istanza:

   gcloud compute instances attach-disk debugger \
      --disk example-disk-debugging
   

7. Segui le istruzioni per connetterti a una VM utilizzando un host bastione.

8. Dopo aver eseguito l'accesso all'istanza del debugger, risolvi i problemi. Ad esempio, puoi esaminare i log delle istanze:

   sudo su -
   

   mkdir /mnt/VM_NAME
   

   mount /dev/disk/by-id/scsi-0Google_PersistentDisk_example-disk-debugging /mnt/VM_NAME
   

   cd /mnt/VM_NAME/var/log
   

   # Identify the issue preventing ssh from working
   ls
   

   Sostituisci VM_NAME con il nome della VM a cui non riesci a collegarti.

Utilizzare uno script di avvio

Se nessuna delle soluzioni precedenti ha risolto il problema, puoi creare uno script di avvio per raccogliere informazioni subito dopo l'avvio dell'istanza. Segui le istruzioni per eseguire uno script di avvio.

Successivamente, devi anche reimpostare l'istanza prima che i metadati vengano applicati utilizzando gcloud compute instances reset.

In alternativa, puoi anche ricreare l'istanza eseguendo uno script di avvio diagnostico:

1. Esegui gcloud compute instances delete con il flag --keep-disks.

   gcloud compute instances delete VM_NAME \
      --keep-disks boot
   

   Sostituisci VM_NAME con il nome della VM a cui non riesci a collegarti.

2. Aggiungi una nuova istanza con lo stesso disco e specifica lo script di avvio.

   gcloud compute instances create NEW_VM_NAME \
      --disk name=BOOT_DISK_NAME,boot=yes \
      --metadata startup-script-url URL
   

   Sostituisci quanto segue:

   • NEW_VM_NAME è il nome della nuova VM che stai creando
   • BOOT_DISK_NAME è il nome del disco di avvio della VM a cui non riesci a connetterti
   • URL è l'URL di Cloud Storage dello script, nel formato gs://BUCKET/FILE o https://storage.googleapis.com/BUCKET/FILE.

Utilizzare il disco su una nuova istanza

Se devi comunque recuperare i dati dal disco di avvio permanente, puoi scollegarlo e collegarlo come disco secondario a una nuova istanza.

1. Elimina la VM a cui non riesci a connetterti e mantieni il relativo disco di avvio:

   gcloud compute instances delete VM_NAME \
      --keep-disks=boot 

   Sostituisci VM_NAME con il nome della VM a cui non riesci a collegarti.

2. Crea una nuova VM con il disco di avvio della vecchia VM. Specifica il nome del disco di avvio della VM appena eliminata.

3. Connettiti alla nuova VM tramite SSH:

   gcloud compute ssh NEW_VM_NAME
   

   Sostituisci NEW_VM_NAME con il nome della nuova VM.

Controlla se il disco di avvio della VM è pieno

La VM potrebbe non essere accessibile se il disco di avvio è pieno. Questo scenario può essere difficile da risolvere perché non è sempre evidente quando il problema di connettività della VM è dovuto a un disco di avvio pieno. Per ulteriori informazioni su questo scenario, consulta la sezione Risolvere i problemi relativi a una VM inaccessibile a causa di un disco di avvio pieno.

Metodi di diagnostica per le VM Windows

Anteprima - SSH for Windows

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Reimpostare i metadati SSH

Se non riesci a connetterti a una VM Windows tramite SSH, prova a reimpostare la chiave dei metadati enable-windows-ssh e riattivare SSH per Windows.

1. Imposta la chiave dei metadati enable-windows-ssh su FALSE. Per informazioni su come impostare i metadati, consulta Impostare metadati personalizzati.

   Attendi qualche secondo affinché la modifica venga applicata.

2. Riattivare SSH per Windows

3. Riconnettiti alla VM.

Connettiti alla VM tramite RDP

Se non riesci a diagnosticare e risolvere la causa delle connessioni SSH non riuscite alla VM Windows, connettiti utilizzando RDP.

Dopo aver stabilito una connessione alla VM, controlla i log di OpenSSH.

Esegui il debug dei problemi SSH con gcpdiag

gcpdiag è uno strumento open source. Non è un prodotto Google Cloud supportato ufficialmente. Puoi utilizzare lo strumento gcpdiag per identificare e risolvere i problemi dei progetti Google Cloud. Per maggiori informazioni, consulta il progetto gcpdiag su GitHub.

Questo runbook gcpdiag esamina le potenziali cause dei problemi di connessione SSH sia sulle VM Windows che su quelle Linux in Google Cloud, esaminando le seguenti aree:

• Integrità della VM: controlla se la VM è in esecuzione e dispone di risorse sufficienti (CPU, memoria, spazio di archiviazione su disco).
• Autorizzazioni:assicurati di disporre delle autorizzazioni IAM necessarie per configurare le chiavi SSH.
• Impostazioni VM:verifica che le chiavi SSH e altri metadati siano configurati correttamente.
• Regole di rete:esamina le regole firewall per verificare che il traffico SSH sia consentito.
• Sistema operativo guest:cerca problemi interni del sistema operativo che potrebbero bloccare SSH.

Console Google Cloud

1. Completa e poi copia il seguente comando.

gcpdiag runbook gce/ssh \
    --parameter project_id=PROJECT_ID \
    --parameter name=VM_NAME \
    --parameter zone=ZONE \
    --parameter principal=PRINCIPAL \
    --parameter tunnel_through_iap=IAP_ENABLED \
    --parameter check_os_login=OS_LOGIN_ENABLED
    --parameter local_user=LOCAL_USER \
    --parameter check_ssh_in_browser=CHECK_SSH_IN_BROWSER

2. Apri la console Google Cloud e attiva Cloud Shell.
Apri Cloud Console
3. Incolla il comando copiato.
4. Esegui il comando gcpdiag, che scarica l'immagine Docker gcpdiag, quindi esegui i controlli diagnostici. Se applicabile, segui le istruzioni di output per risolvere i problemi relativi ai controlli non riusciti.

Docker

Puoi eseguire gcpdiag utilizzando un wrapper che avvia gcpdiag in un container Docker. È necessario installare Docker o Podman.

1. Copia ed esegui il seguente comando sulla tua workstation locale.

   curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag

2. Esegui il comando gcpdiag.

   ./gcpdiag runbook gce/ssh \
       --parameter project_id=PROJECT_ID \
       --parameter name=VM_NAME \
       --parameter zone=ZONE \
       --parameter principal=PRINCIPAL \
       --parameter tunnel_through_iap=IAP_ENABLED \
       --parameter check_os_login=OS_LOGIN_ENABLED
       --parameter local_user=LOCAL_USER \
       --parameter check_ssh_in_browser=CHECK_SSH_IN_BROWSER

Visualizza i parametri disponibili per questo runbook.

Sostituisci quanto segue:

• PROJECT_ID: l'ID del progetto contenente la risorsa
• VM_NAME: il nome della VM di destinazione all'interno del progetto.
• ZONE: la zona in cui si trova la VM di destinazione.
• PRINCIPAL: il principale account utente o di servizio che avvia la connessione SSH. Per l'autenticazione basata su chiavi, utilizza l'utente autenticato dallo strumento a riga di comando Cloud Shell o che ha eseguito l'accesso alla console Google Cloud. Per l'impersonificazione dell'account di servizio, deve essere l'email dell'account di servizio.
• IAP_ENABLED: un valore booleano (true o false) che indica se Identity-Aware Proxy viene utilizzato per stabilire la connessione SSH. Valore predefinito: true
• OS_LOGIN_ENABLED: un valore booleano (true o false) che indica se OS Login viene utilizzato per l'autenticazione SSH. Valore predefinito: true
• LOCAL_USER:utente Posix sulla VM.
• CHECK_SSH_IN_BROWSER:un valore booleano per verificare che SSH nel browser sia fattibile.

Flag utili:

• --universe-domain: se applicabile, il dominio Trusted Partner Sovereign Cloud che ospita la risorsa
• --parameter o -p: parametri del runbook

Per un elenco e una descrizione di tutti i flag dello strumento gcpdiag, consulta le istruzioni per l'utilizzo di gcpdiag.

Passaggi successivi

• Scopri come funzionano le connessioni SSH alle VM Linux su Compute Engine.