Questo documento descrive gli errori comuni che potresti riscontrare durante la connessione alle istanze di macchine virtuali (VM) utilizzando 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: controlla 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 capire se la VM è in esecuzione.
- Test delle impostazioni VPC: controlla la porta SSH predefinita.
Esegui lo strumento di risoluzione dei problemi
Puoi utilizzare la console Google Cloud o Google Cloud CLI per verificare la presenza di problemi di rete e di autorizzazioni degli utenti che potrebbero causare errori nelle connessioni SSH.
Console
Se una connessione SSH non riesce, puoi scegliere Riprovare per eseguire la connessione o risolvere i problemi di connessione utilizzando lo strumento per la risoluzione dei problemi relativi all'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 fornire l'autorizzazione per eseguire i test di risoluzione dei problemi.
Esaminare i risultati
Dopo aver eseguito lo strumento di risoluzione dei problemi, procedi nel seguente modo:
- Esamina i risultati del test per capire perché la connessione SSH della VM non funziona.
- Risolvi le connessioni SSH eseguendo i passaggi di correzione forniti dallo strumento.
Prova a riconnetterti alla VM.
Se la connessione non riesce, prova a risolvere manualmente il problema procedendo nel seguente modo:
Errori SSH comuni
Di seguito sono riportati alcuni esempi di errori comuni che potresti riscontrare quando utilizzi SSH per connetterti alle VM di Compute Engine.
Errori SSH nel browser
Errore 401 non autorizzato
Quando ti connetti alla VM utilizzando l'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 all'interno di Google Workspace ed è presente una limitazione attiva nel criterio di Workspace che impedisce agli utenti di accedere a SSH nel browser e alla console seriale in Google Cloud.
Per risolvere il problema, chiedi a un amministratore di Google Workspace di procedere nel seguente modo:
Verifica che Google Cloud sia abilitato per l'organizzazione.
Se Google Cloud è disabilitato, abilitalo e riprova a stabilire la connessione.
Verifica che i servizi non controllabili individualmente siano attivati.
Se questi servizi sono disabilitati, abilitali e riprova a stabilire la connessione.
Se il problema persiste dopo aver abilitato le impostazioni di Google Cloud in Google Workspace:
Acquisisci il traffico di rete in un file HAR (HTTP Archive Format) a partire dall'avvio della connessione SSH nel browser.
Crea una richiesta di assistenza clienti Google Cloud e allega il file HAR.
Impossibile connettersi, nuovo tentativo in corso...
All'avvio di una sessione SSH può verificarsi il seguente errore:
Could not connect, retrying ...
Per risolvere il problema:
Al termine dell'avvio della VM, riprova a stabilire la connessione. Se la connessione non riesce, verifica che la VM non sia stata avviata in modalità di emergenza eseguendo questo 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 al processo di avvio della VM per identificare dove si verifica l'errore.
Verifica che il servizio
google-guest-agent.service
sia in esecuzione eseguendo questo comando nella console seriale.systemctl status google-guest-agent.service
Se il servizio è disabilitato, abilitalo e avvialo eseguendo questi comandi:
systemctl enable google-guest-agent.service systemctl start google-guest-agent.service
Verifica che gli script dell'agente Google Linux siano installati e in esecuzione. Per maggiori informazioni, consulta Determinazione dello stato dell'agente Google. Se l'agente Google Linux non è installato, reinstallalo.
Verifica di disporre dei ruoli richiesti per connetterti alla VM. Se la VM utilizza OS Login, consulta l'articolo Assegnare il ruolo IAM OS Login. Se la VM non utilizza OS Login, è necessario il ruolo Amministratore istanze Compute o il ruolo utente account di servizio (se la VM è configurata per essere eseguita come account di servizio). I ruoli sono necessari per aggiornare l'istanza o le chiavi-metadati SSH del progetto.
Verifica che esista una regola firewall che consenta l'accesso SSH eseguendo questo comando:
gcloud compute firewall-rules list | grep "tcp:22"
Verifica che esista una route predefinita verso internet (o al bastion host). Per ulteriori informazioni, vedi Verificare i percorsi.
Assicurati che lo spazio su disco del volume principale non sia esaurito. Per ulteriori informazioni, consulta Risoluzione dei problemi relativi a dischi completi e ridimensionamento dei dischi.
Assicurati che la VM non abbia esaurito la memoria eseguendo questo 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 ha esaurito la memoria, connettiti alla console seriale per risolvere i problemi.
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 archiviata nei metadati per connetterti a una VM in cui è abilitato OS Login. Se OS Login è abilitato nel tuo progetto, la VM non accetta le chiavi SSH archiviate nei metadati. Se non hai la certezza che OS Login sia abilitato, consulta la pagina 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 Connessione alle VM.
- Aggiungi le tue chiavi SSH a OS Login. Per maggiori informazioni, consulta Aggiungere chiavi alle VM che utilizzano OS Login.
- Disattiva OS Login. Per maggiori informazioni, consulta Disattivare OS Login.
Hai utilizzato una chiave SSH archiviata in un profilo OS Login per connetterti a una VM in cui non è abilitato OS Login. Se disabiliti OS Login, la VM non accetta le chiavi SSH archiviate nel tuo profilo di OS Login. Se non hai la certezza che OS Login sia abilitato, consulta la sezione 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 Connessione alle VM.
- Attiva OS Login. Per maggiori informazioni, consulta Attivazione di OS Login.
- Aggiungi le tue chiavi SSH ai metadati. Per ulteriori informazioni, 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 hai la certezza che OS Login sia abilitato, consulta la pagina Verificare se OS Login è configurato.
Per risolvere il problema, concedi i ruoli IAM richiesti per OS Login.
La chiave è scaduta e Compute Engine ha eliminato il tuo file
~/.ssh/authorized_keys
. Se hai aggiunto manualmente chiavi SSH alla VM e poi ti sei connesso alla VM tramite la console Google Cloud, Compute Engine ha creato una nuova coppia di chiavi per la connessione. Una volta scaduta la 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 Connessione alle VM.
- Aggiungi nuovamente la chiave SSH ai metadati. Per ulteriori informazioni, consulta Aggiungere chiavi SSH alle VM che utilizzano chiavi SSH basate su metadati.
Hai effettuato la connessione tramite uno strumento di terze parti e il tuo comando SSH non è configurato correttamente. Se ti connetti utilizzando il comando
ssh
ma non specifichi un percorso per la tua chiave privata o se specifichi un percorso errato per la tua chiave privata, 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 corrisponde a quello che hai 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 tua VM.
- Connettiti alla VM utilizzando la console Google Cloud o Google Cloud CLI. Quando utilizzi questi strumenti per connetterti, Compute Engine gestisce la creazione delle chiavi per te. Per maggiori informazioni, consulta Connessione alle VM.
- Esegui questo comando:
L'ambiente guest della tua VM non è in esecuzione. Se è la prima volta che ti connetti alla VM e l'ambiente guest non è in esecuzione, la VM potrebbe rifiutare la richiesta di connessione SSH.
Per risolvere il problema:
- Riavvia la VM.
- 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 Convalida dell'ambiente guest.
- Se l'ambiente guest non è in esecuzione, installalo manualmente clonando il disco di avvio della VM e utilizzando uno script di avvio.
Il daemon 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, prova una o più delle seguenti operazioni:
Consulta la guida dell'utente relativa al tuo sistema operativo per assicurarti che
sshd_config
sia configurato correttamente.Assicurati di disporre delle impostazioni di proprietà e autorizzazione necessarie per:
- Directory
$HOME
e$HOME/.ssh
- File
$HOME/.ssh/authorized_keys
Proprietà
L'ambiente guest archivia le chiavi pubbliche SSH autorizzate nel file
$HOME/.ssh/authorized_keys
. 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
,0750
o0755
*$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 per la tua distribuzione Linux specifica.
In alternativa, puoi creare una nuova VM basata sulla stessa immagine e controllare le relative autorizzazioni predefinite per
$HOME
.Per scoprire come modificare le autorizzazioni e la proprietà, leggi le informazioni su
chmod
echown
.- Directory
Riavvia
sshd
eseguendo questo comando:systemctl restart sshd.service
Verifica se ci sono errori nello stato eseguendo questo 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 la risoluzione dei problemi.
Il disco di avvio della VM è pieno. Quando viene stabilita una connessione SSH, l'ambiente ospite aggiunge la chiave SSH pubblica 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 eseguendo il debug con la console seriale per identificare
no space left errors
. - Ridimensiona il disco.
- Se sai quali file utilizzano spazio su disco, crea uno script di avvio che elimini i file non necessari e libera spazio. Dopo che la VM viene avviata e ti sei connesso, elimina i metadati
startup-script
.
- Verifica che il disco di avvio sia pieno eseguendo il debug con la console seriale per identificare
Le autorizzazioni o la proprietà su
$HOME
,$HOME/.ssh
o$HOME/.ssh/authorized_keys
sono errate.Proprietà
L'ambiente guest archivia le chiavi pubbliche SSH autorizzate nel file
$HOME/.ssh/authorized_keys
. 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
,0750
o0755
*$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 per la tua distribuzione Linux specifica.
In alternativa, puoi creare una nuova VM basata sulla stessa immagine e controllare le relative autorizzazioni predefinite per
$HOME
.Per scoprire come modificare le autorizzazioni e la proprietà, leggi le informazioni su
chmod
echown
.
Connessione non riuscita
Quando ti connetti alla VM dalla console Google Cloud, da gcloud CLI, da un bastion host o da un client locale, possono verificarsi i seguenti errori:
La 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 di questi errori:
La VM è in fase di avvio e
sshd
non è ancora in esecuzione. Non puoi connetterti a una VM prima che sia in esecuzione.Per risolvere il problema, attendi il termine dell'avvio della VM e riprova a connetterti.
sshd
è in esecuzione su una porta personalizzata. Se hai configuratosshd
per l'esecuzione su una porta diversa dalla porta 22, non potrai connetterti alla tua VM.Per risolvere il problema, crea una regola firewall personalizzata che consenta il traffico
tcp
sulla porta su cui è in esecuzionesshd
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 Creazione di regole firewall.
La regola firewall SSH non è presente o non consente il traffico da IAP o dalla rete internet pubblica. Le connessioni SSH vengono rifiutate se le regole firewall non consentono connessioni dal traffico IAP o in entrata TCP per l'intervallo IP
0.0.0.0/0
.Per risolvere il problema, procedi in uno dei seguenti modi:
Se utilizzi Identity-Aware Proxy (IAP) per l'inoltro TCP, aggiorna la regola firewall personalizzata per accettare il traffico da IAP, quindi controlla le autorizzazioni IAM.
- 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. - Concedi le autorizzazioni per utilizzare l'inoltro TCP IAP, se non l'hai già fatto.
- Aggiorna la regola firewall personalizzata per consentire il traffico da
Se non utilizzi IAP, aggiorna la regola firewall personalizzata per consentire il traffico SSH in entrata.
- Aggiorna la regola firewall personalizzata in modo da Consentire connessioni SSH in entrata alle VM.
La connessione SSH non è riuscita dopo l'upgrade del kernel della VM. Una VM potrebbe riscontrare un panic del kernel dopo un aggiornamento del kernel, che ne fa diventare inaccessibile.
Per risolvere il problema:
- Installa il disco su un'altra VM.
- Aggiorna il file
grub.cfg
per usare la versione precedente del kernel. - Collega il disco alla VM che non risponde.
- Verifica che lo stato della VM sia
RUNNING
utilizzando il comandogcloud compute instances describe
. - Reinstalla il kernel.
- Riavvia la VM.
In alternativa, se hai creato uno snapshot del disco di avvio prima di eseguire l'upgrade della VM, utilizzalo per creare una VM.
Il daemon 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, prova una o più delle seguenti operazioni:
Consulta la guida dell'utente relativa al tuo sistema operativo per assicurarti che
sshd_config
sia configurato correttamente.Assicurati di disporre delle impostazioni di proprietà e autorizzazione necessarie per:
- Directory
$HOME
e$HOME/.ssh
- File
$HOME/.ssh/authorized_keys
Proprietà
L'ambiente guest archivia le chiavi pubbliche SSH autorizzate nel file
$HOME/.ssh/authorized_keys
. 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
,0750
o0755
*$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 per la tua distribuzione Linux specifica.
In alternativa, puoi creare una nuova VM basata sulla stessa immagine e controllare le relative autorizzazioni predefinite per
$HOME
.Per scoprire come modificare le autorizzazioni e la proprietà, leggi le informazioni su
chmod
echown
.- Directory
Riavvia
sshd
eseguendo questo comando:systemctl restart sshd.service
Verifica se ci sono errori nello stato eseguendo questo 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 la risoluzione dei problemi.
La VM non si avvia e non puoi connetterti tramite SSH o la console seriale. Se la VM è inaccessibile, il sistema operativo potrebbe essere danneggiato. Se il disco di avvio non si avvia, puoi diagnosticare il problema. Se vuoi ripristinare la VM danneggiata e recuperare i dati, consulta Recupero di una VM danneggiata o di un disco di avvio completo.
La VM è in fase di avvio in modalità di manutenzione. Quando viene avviata 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:
Se non hai impostato una password root per la VM, utilizza uno 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.
Riavvia la VM.
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 daemon 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, prova una o più delle seguenti operazioni:
Consulta la guida dell'utente relativa al tuo sistema operativo per assicurarti che
sshd_config
sia configurato correttamente.Assicurati di disporre delle impostazioni di proprietà e autorizzazione necessarie per:
- Directory
$HOME
e$HOME/.ssh
- File
$HOME/.ssh/authorized_keys
Proprietà
L'ambiente guest archivia le chiavi pubbliche SSH autorizzate nel file
$HOME/.ssh/authorized_keys
. 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
,0750
o0755
*$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 per la tua distribuzione Linux specifica.
In alternativa, puoi creare una nuova VM basata sulla stessa immagine e controllare le relative autorizzazioni predefinite per
$HOME
.Per scoprire come modificare le autorizzazioni e la proprietà, leggi le informazioni su
chmod
echown
.- Directory
Riavvia
sshd
eseguendo questo comando:systemctl restart sshd.service
Verifica se ci sono errori nello stato eseguendo questo 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 la risoluzione dei problemi.
Problema del daemon SSH sconosciuto. Per diagnosticare un problema sconosciuto del daemon SSH, verifica la presenza di 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 seguendo questi passaggi:
- Collega il disco a un'altra VM Linux.
- Connettiti alla VM in cui è installato il disco.
- Monta il disco all'interno del sistema operativo su una directory MOUNT_DIR all'interno della VM.
- Visualizza i log relativi a SSH,
/var/log/secure
o/var/log/auth.log
per individuare eventuali problemi/errori. Se riscontri problemi da risolvere, prova a risolverli. In caso contrario, crea una richiesta di assistenza e allega i log. Smonta il disco dal sistema operativo utilizzando il comando
umount
:cd ~/ umount /mnt
Scollega il disco dalla VM.
Collega il disco alla VM originale.
Avviare la VM.
Impossibile connettersi al backend
Quando ti connetti alla VM dalla console Google Cloud o da gcloud CLI, potrebbero verificarsi i seguenti errori:
La 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 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 file ~/.ssh/known_hosts
, quindi riprova a stabilire la connessione.
Il valore dei metadati è troppo grande
Quando provi ad aggiungere una nuova chiave SSH ai metadati, può 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 mitigare questo limite, procedi in uno dei seguenti modi:
- Elimina le chiavi SSH scadute o duplicate dai metadati di progetto o istanza. Per ulteriori informazioni, consulta Aggiornare i metadati su una VM in esecuzione.
- Utilizza OS Login.
Errori di Windows
Autorizzazione negata, riprova
Quando ti connetti alla VM potrebbe verificarsi il seguente errore:
USERNAME@compute.INSTANCE_ID's password: Permission denied, please try again.
Questo errore indica che l'utente che sta tentando di connettersi alla VM non esiste nella VM. Di seguito sono riportate alcune delle cause più comuni di questo errore:
La tua versione di gcloud CLI non è aggiornata
Se gcloud CLI non è aggiornato, è possibile che tu stia tentando di connetterti utilizzando un nome utente non configurato. Per risolvere il problema, aggiorna gcloud CLI.
Hai provato a connetterti a una VM Windows per cui non è abilitato SSH.
Per risolvere questo errore, imposta la chiave
enable-windows-ssh
suTRUE
nei metadati del progetto o dell'istanza. Per ulteriori informazioni sull'impostazione dei metadati, consulta Impostazione dei metadati personalizzati.
Autorizzazione negata (publickey,keyboard-interactive)
Quando ti connetti a una VM in cui non è abilitato 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
Impostazione dei metadati personalizzati.
Impossibile accedere tramite SSH all'istanza
Quando ti connetti alla VM da gcloud 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 di questi 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 di OpenSSH Server per Windows Server e Windows per verificare che
sshd
sia configurato correttamente.
Timeout della connessione
Le connessioni SSH scadute potrebbero essere causate da una delle seguenti cause:
L'avvio della VM non è terminato. Attendi un po' di tempo per l'avvio della VM.
Per risolvere il problema, attendi il termine dell'avvio della VM e riprova a connetterti.
Il pacchetto SSH non è installato. Le VM Windows richiedono l'installazione del pacchetto
google-compute-engine-ssh
per poterti connettere tramite SSH.Per risolvere questo problema, installa il pacchetto SSH.
Diagnosi delle connessioni SSH non riuscite
Le seguenti sezioni descrivono i passaggi che puoi seguire per diagnosticare la causa delle connessioni SSH non riuscite e i passaggi per correggerle.
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 che non esegue l'ambiente guest, installa l'ambiente guest Linux.
- Se utilizzi OS Login, consulta la pagina Risoluzione dei problemi di OS Login.
Metodi di diagnosi per VM Linux e Windows
Testa la connettività
Potresti non essere in grado di stabilire una connessione a un'istanza VM tramite SSH a causa di problemi di connettività collegati 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 di firewall e assicurarti che sia presente la regola default-allow-ssh
.
Sulla workstation locale, esegui questo comando:
gcloud compute firewall-rules list
Se manca la regola firewall, 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, usa 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.
Test della connessione di rete
Per determinare se la connessione di rete funziona, testa l'handshake TCP:
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 connetterti.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 precedentePORT_NUMBER
: il numero di porta
Se l'handshake TCP ha esito positivo, 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 un handshake TCP riuscito.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 precedentePORT_NUMBER
: il numero di porta
Se l'handshake TCP ha esito positivo, 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 un handshake TCP riuscito.
Se l'handshake TCP viene completato correttamente, una regola firewall software non blocca la connessione, il sistema operativo inoltra correttamente i pacchetti e un server è in ascolto sulla porta di destinazione. Se l'handshake TCP viene completato correttamente, ma la VM non accetta connessioni SSH, il problema potrebbe essere dovuto al fatto 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 utente. Ad esempio, le autorizzazioni sul file ~/.ssh/authorized_keys
nell'istanza potrebbero non essere impostate correttamente per l'utente.
Prova ad accedere come un altro utente con gcloud CLI
specificando ANOTHER_USERNAME
con la richiesta SSH.
gcloud CLI 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 tuoVM_NAME
è il nome della VM a cui vuoi connetterti
Debug dei problemi utilizzando la console seriale
Ti consigliamo di esaminare i log della console seriale per individuare eventuali errori di connessione. Puoi accedere alla console seriale come utente root dalla workstation locale utilizzando un browser. Questo approccio è utile se non puoi accedere con SSH o se l'istanza non ha una connessione alla rete. La console seriale rimane accessibile in entrambe le situazioni.
Per accedere alla console seriale della VM e risolvere i problemi della VM, segui questi passaggi:
Abilita l'accesso interattivo alla console seriale della VM.
Per le VM Linux, modifica la password root e aggiungi il seguente script di avvio alla VM:
echo root:PASSWORD | chpasswd
Sostituisci PASSWORD con una password di tua scelta.
Utilizza la console seriale per connetterti alla VM.
Per le VM Linux, dopo aver completato il debug di tutti gli errori, disattiva l'accesso all'account principale:
sudo passwd -l root
Metodi di diagnosi per VM Linux
Esamina l'istanza VM senza arrestarla
Potresti avere un'istanza a cui non puoi connetterti che continua a gestire correttamente il traffico di produzione. In questo caso ti conviene ispezionare il disco senza interrompere l'istanza.
Per ispezionare il disco e risolvere i problemi:
- Esegui il backup del disco di avvio creando uno snapshot del disco.
- Crea un disco permanente standard a partire da questo snapshot.
- Crea un'istanza temporanea.
- Collega e monta il disco permanente standard sulla nuova istanza temporanea.
Questa procedura crea una rete isolata che consente solo connessioni SSH. Questa configurazione impedisce eventuali conseguenze indesiderate dell'interferenza dell'istanza clonata con i servizi di produzione.
Crea una nuova rete VPC per ospitare la tua istanza clonata:
gcloud compute networks create debug-network
Sostituisci
NETWORK_NAME
con il nome che vuoi chiamare della nuova rete.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
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.Crea un nuovo disco con lo snapshot che hai appena creato:
gcloud compute disks create example-disk-debugging \ --source-snapshot debug-disk-snapshot
Crea una nuova istanza di debug senza un indirizzo IP esterno:
gcloud compute instances create debugger \ --network debug-network \ --no-address
Collega il disco di debug all'istanza:
gcloud compute instances attach-disk debugger \ --disk example-disk-debugging
Segui le istruzioni per connettersi a una VM utilizzando un bastion host.
Dopo aver eseguito l'accesso all'istanza del debugger, risolvi i problemi relativi all'istanza. Ad esempio, puoi esaminare i log dell'istanza:
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 connetterti.
Usa uno script di avvio
Se nessuna delle soluzioni precedenti è stata utile, puoi creare uno script di avvio per raccogliere informazioni subito dopo l'avvio dell'istanza. Segui le istruzioni per eseguire uno script di avvio.
In seguito, dovrai 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:
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 connetterti.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 creandoBOOT_DISK_NAME
è il nome del disco di avvio della VM a cui non riesci a connettertiURL
è l'URL di Cloud Storage allo script, in formatogs://BUCKET/FILE
ohttps://storage.googleapis.com/BUCKET/FILE
.
Utilizza il tuo disco su una nuova istanza
Se hai ancora bisogno di recuperare i dati dal disco di avvio permanente, puoi scollegare il disco di avvio e collegarlo come disco secondario in una nuova istanza.
Elimina la VM a cui non riesci a connetterti e conserva 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 connetterti.Crea una nuova VM con il disco di avvio della vecchia VM. Specifica il nome del disco di avvio della VM appena eliminata.
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 o meno
La VM potrebbe non essere più accessibile se il disco di avvio è pieno. Questo scenario può essere difficile da risolvere in quanto non è sempre evidente quando il problema di connettività della VM è dovuto a un disco di avvio pieno. Per ulteriori informazioni su questo scenario, consulta Risolvere i problemi relativi a una VM inaccessibile a causa di un disco di avvio pieno.
Metodi di diagnosi per le VM Windows
Reimposta metadati SSH
Se non riesci a connetterti a una VM Windows tramite SSH, prova a annullare la chiave di metadati enable-windows-ssh
e a riattivare SSH per Windows.
Imposta la chiave dei metadati
enable-windows-ssh
suFALSE
. Per informazioni su come impostare i metadati, consulta Impostare i metadati personalizzati.Attendi qualche secondo affinché la modifica venga applicata.
Connettiti alla VM utilizzando RDP
Se non riesci a diagnosticare e risolvere la causa delle connessioni SSH non riuscite alla tua VM Windows, connettiti tramite RDP.
Dopo aver stabilito una connessione alla VM, esamina i log OpenSSH.
Debug dei problemi relativi a SSH con gcpdiag
gcpdiag
è uno strumento open source che consente di identificare e risolvere i problemi relativi ai progetti
Google Cloud. gcpdiag
non è un prodotto Google Cloud ufficialmente supportato. Per maggiori
informazioni, consulta il
progetto GCPdiag su GitHub.
- Integrità della VM: controlla se la VM è in esecuzione e ha risorse sufficienti (CPU, memoria, spazio di archiviazione su disco).
- Autorizzazioni: verifica di disporre delle autorizzazioni IAM corrette per configurare le chiavi SSH.
- Impostazioni VM: verifica che le chiavi SSH e gli altri metadati siano configurati correttamente.
- Regole di rete: esamina le regole firewall per confermare che il traffico SSH sia consentito.
- Sistema operativo guest: cerca problemi interni del sistema operativo che potrebbero bloccare SSH.
Cloud Shell
- Copia ed esegui questo comando in Cloud Shell:
gcpdiag runbook gce/ssh --project=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
-
Console Google Cloud
- Copia il seguente comando:
- Apri la console Google Cloud e attiva Cloud Shell: Apri la console Cloud
- Incolla il comando copiato.
- Esegui il comando gcpdiag. Verrà scaricata l'immagine Docker gcpdiag e inizierà a eseguire i controlli pertinenti per questo comando. Segui le istruzioni su come correggere i controlli non riusciti.
gcpdiag runbook gce/ssh --project=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
Docker
Puoi
eseguire gcpdiag
utilizzando un wrapper che avvia gcpdiag
in un container Docker.
Funziona su qualsiasi macchina in cui è installato Docker o Podman.
- Copia ed esegui il comando seguente nella workstation locale:
curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
- Esegui il comando
gcpdiag
:./gcpdiag runbook gce/ssh --project=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
Visualizza tutti 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 target.
- PRINCIPAL: l'entità dell'account utente o di servizio che avvia la connessione SSH. Per l'autenticazione basata su chiave, utilizza l'utente autenticato dallo strumento a riga di comando di Cloud Shell o ha eseguito l'accesso alla console Google Cloud. Per la simulazione dell'identità dell'account di servizio, deve essere l'email dell'account di servizio.
- IAP_ENABLED: un valore booleano (true o false)
che indica se viene utilizzato Identity-Aware Proxy per stabilire la connessione SSH.
Predefinita:
true
- OS_LOGIN_ENABLED: un valore booleano (true o false)
che indica se l'OS Login viene utilizzato per l'autenticazione SSH. Predefinita:
true
Flag utili:
--project
: per definire il valore PROJECT_ID.--universe-domain
: se applicabile, utilizzato per definire il dominio Trusted Partner Sovereign Cloud che ospita la risorsa.--parameter
o-p
: per definire i parametri per un runbook.
Per maggiori informazioni sui flag disponibili, consulta le istruzioni sull'utilizzo
di gcpdiag
.
Passaggi successivi
- Scopri come funzionano le connessioni SSH alle VM Linux su Compute Engine.