Solucionar problemas de errores de SSH

En este documento se describen los errores habituales que pueden surgir al conectarse a instancias de máquinas virtuales (VMs) mediante SSH, las formas de resolverlos y los métodos para diagnosticar las conexiones SSH fallidas.

Herramienta para solucionar problemas de SSH

Usa la herramienta de solución de problemas de SSH para determinar por qué ha fallado una conexión SSH. La herramienta de solución de problemas realiza las siguientes pruebas para comprobar la causa de los fallos en las conexiones SSH:

  • Pruebas de permisos de usuario: comprueba si tienes los permisos de gestión de identidades y accesos necesarios para conectarte a la VM mediante SSH.
  • Pruebas de conectividad de red: comprueba si la VM está conectada a la red.
  • Pruebas de estado de la instancia de VM: comprueba el estado de la CPU de la VM para ver si está en ejecución.
  • Pruebas de configuración de VPC: comprueba el puerto SSH predeterminado.

Ejecutar la herramienta para solucionar problemas

Puedes usar la Google Cloud consola o la CLI de Google Cloud para comprobar si hay problemas de red y errores de permisos de usuario que puedan provocar que fallen las conexiones SSH.

Consola

Si falla una conexión SSH, puedes reintentar la conexión o solucionar el problema con la herramienta de solución de problemas de SSH en el navegador.

Para ejecutar la herramienta de solución de problemas, haz clic en Solucionar problemas.

Inicia la herramienta para solucionar problemas de SSH.

gcloud

Ejecuta la herramienta para solucionar problemas con el comando gcloud compute ssh:

gcloud compute ssh VM_NAME \
    --troubleshoot

Sustituye VM_NAME por el nombre de la VM a la que no puedes conectarte.

La herramienta te pedirá permiso para realizar las pruebas de solución de problemas.

Revisar los resultados

Después de ejecutar la herramienta para solucionar problemas, haz lo siguiente:

  1. Revisa los resultados de la prueba para saber por qué no funciona la conexión SSH de la VM.
  2. Resuelve las conexiones SSH siguiendo los pasos de corrección que proporciona la herramienta.

  3. Prueba a volver a conectarte a la VM.

    Si la conexión no se establece correctamente, prueba a solucionar el problema manualmente siguiendo estos pasos:

Errores habituales de SSH

A continuación, se muestran ejemplos de errores habituales que pueden producirse al usar SSH para conectarse a VMs de Compute Engine.

Errores de SSH en el navegador

Error 401 (sin autorización)

Puede que se produzca el siguiente error al conectarte a tu VM mediante SSH en el navegador desde la consola Google Cloud :

Unauthorized
Error 401

Este error se produce si tu usuario forma parte de una organización que se gestiona desde Google Workspace y hay una restricción activa en la política de Workspace que impide que los usuarios accedan a SSH en el navegador y a la consola serie en Google Cloud.

Para solucionar este problema, pide a un administrador de Google Workspace que haga lo siguiente:

  1. Confirma que Google Cloud está habilitado en la organización.

    Si Google Cloud está inhabilitado, habilítalo y vuelve a intentar la conexión.

  2. Comprueba que los servicios que no se pueden controlar por separado estén habilitados.

    Si estos servicios están inhabilitados, habilítalos y vuelve a intentar la conexión.

Si el problema persiste después de habilitar los ajustes de Google Cloud Google Workspace, haz lo siguiente:

  1. Captura el tráfico de red en un archivo HAR (HTTP Archive Format) desde el momento en que inicies la conexión SSH en el navegador.

  2. Crea un caso de asistencia de Cloud Customer Care y adjunta el archivo HAR.

No se ha podido conectar. Volviéndolo a intentar...

Puede que se produzca el siguiente error al iniciar una sesión SSH: 

Could not connect, retrying ...

No se ha podido conectar. Volviéndolo a intentar

Para solucionar este problema, sigue estos pasos:

  1. Cuando la VM haya terminado de arrancar, vuelve a intentar la conexión. Si la conexión no se establece correctamente, comprueba que la VM no se haya iniciado en modo de emergencia ejecutando el siguiente comando:

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

    Si la VM se inicia en modo de emergencia, soluciona los problemas del proceso de inicio de la VM para identificar en qué parte falla.

  2. Verifica que el servicio google-guest-agent.service se esté ejecutando. Para ello, ejecuta el siguiente comando en la consola serie.

    systemctl status google-guest-agent.service

    Si el servicio está inhabilitado, habilítalo e inícialo ejecutando los siguientes comandos:

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

  3. Comprueba que los scripts del agente de Google para Linux estén instalados y en ejecución. Para obtener más información, consulta Determinar el estado del agente de Google. Si el agente de Google para Linux no está instalado, vuelve a instalarlo.

  4. Comprueba que tienes los roles necesarios para conectarte a la VM. Si tu VM usa OS Login, consulta Asignar el rol de gestión de identidades y accesos de OS Login. Si la VM no usa el inicio de sesión del SO, necesitas el rol de administrador de instancias de Compute o el rol de usuario de cuenta de servicio (si la VM está configurada para ejecutarse como una cuenta de servicio). Los roles son necesarios para actualizar los metadatos de las claves SSH de la instancia o del proyecto.

  5. Para comprobar que hay una regla de cortafuegos que permite el acceso SSH, ejecuta el siguiente comando:

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

  6. Verifica que haya una ruta predeterminada a Internet (o al host bastion). Para obtener más información, consulta Comprobar rutas.

  7. Asegúrate de que el volumen raíz no se haya quedado sin espacio en disco. Para obtener más información, consulta Solucionar problemas con discos completos y modificar su tamaño.

  8. Comprueba que la máquina virtual no se haya quedado sin memoria ejecutando el siguiente 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"

    Si la VM se queda sin memoria, conéctate a la consola en serie para solucionar el problema.

Errores de Linux

Permiso denegado (clave pública)

Puede producirse el siguiente error al conectarte a tu VM:

USERNAME@VM_EXTERNAL_IP: Permission denied (publickey).

Este error puede deberse a varios motivos. Estas son algunas de las causas más habituales de este error:

  • Has usado una clave SSH almacenada en metadatos para conectarte a una VM que tiene habilitado el inicio de sesión en el SO. Si OS Login está habilitado en tu proyecto, tu VM no aceptará las claves SSH almacenadas en los metadatos. Si no sabes si OS Login está habilitado, consulta Comprobar si OS Login está configurado.

    Para solucionar este problema, prueba una de las siguientes opciones:

  • Has usado una clave SSH almacenada en un perfil de OS Login para conectarte a una VM que no tiene habilitado OS Login. Si inhabilitas OS Login, tu VM no aceptará las claves SSH que se hayan almacenado en tu perfil de OS Login. Si no sabes si OS Login está habilitado, consulta Comprobar si OS Login está configurado.

    Para solucionar este problema, prueba una de las siguientes opciones:

  • La VM tiene habilitado OS Login, pero no tienes permisos de gestión de identidades y accesos suficientes para usarlo. Para conectarse a una VM que tenga habilitado OS Login, debe tener los permisos necesarios para OS Login. Si no sabes si OS Login está habilitado, consulta Comprobar si OS Login está configurado.

    Para solucionar este problema, concede los roles de gestión de identidades y accesos (IAM) de inicio de sesión con SO necesarios.

  • Tu clave ha caducado y Compute Engine ha eliminado el archivo ~/.ssh/authorized_keys. Si has añadido manualmente claves SSH a tu máquina virtual y, a continuación, te has conectado a ella mediante la Google Cloud consola, Compute Engine ha creado un nuevo par de claves para tu conexión. Una vez que ha caducado el nuevo par de claves, Compute Engine ha eliminado el archivo ~/.ssh/authorized_keys de la VM, que incluía la clave SSH que habías añadido manualmente.

    Para solucionar este problema, prueba una de las siguientes opciones:

  • Te has conectado mediante una herramienta de terceros y tu comando SSH está mal configurado. Si te conectas mediante el comando ssh, pero no especificas una ruta a tu clave privada o especificas una ruta incorrecta, tu VM rechazará la conexión.

    Para solucionar este problema, prueba una de las siguientes opciones:

    • Ejecuta el siguiente comando:
      ssh -i PATH_TO_PRIVATE_KEY USERNAME@EXTERNAL_IP

      Sustituye lo siguiente:
      • PATH_TO_PRIVATE_KEY: la ruta al archivo de tu clave SSH privada.
      • USERNAME: nombre de usuario del usuario que se conecta a la instancia. Si gestionas tus claves SSH en los metadatos, el nombre de usuario es el que especificaste cuando creaste la clave SSH. En las cuentas de inicio de sesión del SO, el nombre de usuario se define en tu perfil de Google.
      • EXTERNAL_IP: la dirección IP externa de tu máquina virtual.
    • Conéctate a tu VM mediante la Google Cloud consola o la CLI de Google Cloud. Cuando usas estas herramientas para conectarte, Compute Engine gestiona la creación de claves por ti. Para obtener más información, consulta Conectarse a VMs.

  • El entorno de invitado de tu máquina virtual no se está ejecutando. Si es la primera vez que te conectas a tu máquina virtual y el entorno invitado no se está ejecutando, es posible que la máquina virtual rechace tu solicitud de conexión SSH.

    Para solucionar este problema, sigue estos pasos:

    1. Reinicia la VM.
    2. En la consola Google Cloud , inspecciona los registros de inicio del sistema en la salida del puerto serie para determinar si el entorno invitado se está ejecutando. Para obtener más información, consulta Validar el entorno de invitado.
    3. Si el entorno invitado no se está ejecutando, instálalo manualmente clonando el disco de arranque de la VM y usando un script de inicio.

  • El daemon OpenSSH (sshd) no se está ejecutando o no se ha configurado correctamente. La sshd proporciona acceso remoto seguro al sistema mediante el protocolo SSH. Si está mal configurado o no se está ejecutando, no podrás conectarte a tu máquina virtual mediante SSH.

    Para solucionar este problema, prueba una o varias de las siguientes opciones:

    • Consulta la guía del usuario de tu sistema operativo para asegurarte de que tu sshd_config esté configurado correctamente.

    • Asegúrate de que tienes la propiedad y los permisos necesarios para lo siguiente:

      • Directorios $HOME y $HOME/.ssh
      • Archivo $HOME/.ssh/authorized_keys

      Propiedad

      El entorno de invitado almacena las claves públicas SSH autorizadas en el archivo $HOME/.ssh/authorized_keys. El propietario de los directorios $HOME y $HOME/.ssh y del archivo $HOME/.ssh/authorized_keys debe ser el mismo que el usuario que se conecta a la VM.

      Permisos

      El entorno de invitado requiere los siguientes permisos de Linux:

      Ruta Permisos
      /home 0755
      $HOME 0700 o 0750 o 0755 *
      $HOME/.ssh 0700
      $HOME/.ssh/authorized_keys 0600

      * Para saber cuál es el permiso predeterminado correcto para tu directorio $HOME, consulta la documentación oficial de tu distribución de Linux.

      También puedes crear una VM a partir de la misma imagen y comprobar sus permisos predeterminados para $HOME.

      Para saber cómo cambiar los permisos y la propiedad, consulta los artículos sobre chmod y chown.

    • Reinicia el sshd ejecutando el siguiente comando:

      systemctl restart sshd.service

      Comprueba si hay algún error en el estado ejecutando el siguiente comando:

      systemctl status sshd.service

      La salida del estado puede contener información como el código de salida, el motivo del fallo, etc. Puedes usar estos detalles para seguir solucionando el problema.

  • El disco de arranque de la VM está lleno. Cuando se establece una conexión SSH, el entorno invitado añade la clave SSH pública de la sesión al archivo ~/.ssh/authorized_keys. Si el disco está lleno, la conexión fallará.

    Para solucionar este problema, realice una o varias de las siguientes acciones:

  • Los permisos o la propiedad de $HOME, $HOME/.ssh o $HOME/.ssh/authorized_keys son incorrectos.

    Propiedad

    El entorno de invitado almacena las claves públicas SSH autorizadas en el archivo $HOME/.ssh/authorized_keys. El propietario de los directorios $HOME y $HOME/.ssh y del archivo $HOME/.ssh/authorized_keys debe ser el mismo que el usuario que se conecta a la VM.

    Permisos

    El entorno de invitado requiere los siguientes permisos de Linux:

    Ruta Permisos
    /home 0755
    $HOME 0700 o 0750 o 0755 *
    $HOME/.ssh 0700
    $HOME/.ssh/authorized_keys 0600

    * Para saber cuál es el permiso predeterminado correcto para tu directorio $HOME, consulta la documentación oficial de tu distribución de Linux.

    También puedes crear una VM a partir de la misma imagen y comprobar sus permisos predeterminados para $HOME.

    Para saber cómo cambiar los permisos y la propiedad, consulta los artículos sobre chmod y chown.

Error de conexión

Pueden producirse los siguientes errores al conectarse a una VM desde la consolaGoogle Cloud , la CLI de gcloud, un host bastion o un cliente local:

  • La consola Google Cloud :

    Connection Failed

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

  • La CLI de gcloud:

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

  • Un host bastión o un cliente local:

    port 22: Connection timed out.

    port 22: Connection refused

Estos errores pueden deberse a varios motivos. A continuación, se indican algunas de las causas más habituales de los errores:

  • La VM se está iniciando y sshd aún no se está ejecutando. No puedes conectarte a una VM antes de que se esté ejecutando.

    Para solucionar este problema, espera a que la VM haya terminado de iniciarse e intenta conectarte de nuevo.

  • sshd se está ejecutando en un puerto personalizado. Si has configurado sshd para que se ejecute en un puerto distinto del 22, no podrás conectarte a tu VM.

    Para solucionar este problema, cree una regla de cortafuegos personalizada que permita el tráfico de tcp en el puerto en el que se ejecuta su sshd mediante el siguiente comando:

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

    Para obtener más información sobre cómo crear reglas de cortafuegos personalizadas, consulta Crear reglas de cortafuegos.

  • Falta la regla de cortafuegos de SSH o no permite el tráfico de IAP o de la red pública de Internet. Las conexiones SSH se rechazan si las reglas de cortafuegos no permiten las conexiones del tráfico de entrada de IAP o TCP para el intervalo de IPs 0.0.0.0/0.

    Para solucionar este problema, haz una de las siguientes acciones:

    • Si usas Identity-Aware Proxy (IAP) para reenviar TCP, actualiza tu regla de cortafuegos personalizada para aceptar el tráfico de IAP y, a continuación, comprueba tus permisos de IAM.

      1. Actualiza tu regla de cortafuegos personalizada para permitir el tráfico de 35.235.240.0/20, el intervalo de direcciones IP que usa IAP para el reenvío de TCP. Para obtener más información, consulta Crear una regla de cortafuegos.
      2. Concede permisos para usar el reenvío de TCP de IAP, si aún no lo has hecho.

    • Si no usas IAP, actualiza tu regla de cortafuegos personalizada para permitir el tráfico SSH de entrada.

      1. Actualiza tu regla de cortafuegos personalizada para permitir conexiones SSH de entrada a las VMs.

  • La conexión SSH ha fallado después de actualizar el kernel de la VM. Una VM puede experimentar un pánico del kernel después de una actualización del kernel, lo que provoca que la VM se vuelva inaccesible.

    Para solucionar este problema, sigue estos pasos:

    1. Monta el disco en otra máquina virtual.
    2. Actualiza el archivo grub.cfg para usar la versión anterior del kernel.
    3. Acopla el disco a la VM que no responde.
    4. Verifica que el estado de la VM sea RUNNING con el comando gcloud compute instances describe.
    5. Vuelve a instalar el kernel.
    6. Reinicia la VM.

    También puedes crear una máquina virtual a partir de la captura si has creado una captura del disco de arranque antes de actualizar la máquina virtual.

  • El daemon OpenSSH (sshd) no se está ejecutando o no se ha configurado correctamente. La sshd proporciona acceso remoto seguro al sistema mediante el protocolo SSH. Si está mal configurado o no se está ejecutando, no podrás conectarte a tu máquina virtual mediante SSH.

    Para solucionar este problema, prueba una o varias de las siguientes opciones:

    • Consulta la guía del usuario de tu sistema operativo para asegurarte de que tu sshd_config esté configurado correctamente.

    • Asegúrate de que tienes la propiedad y los permisos necesarios para lo siguiente:

      • Directorios $HOME y $HOME/.ssh
      • Archivo $HOME/.ssh/authorized_keys

      Propiedad

      El entorno de invitado almacena las claves públicas SSH autorizadas en el archivo $HOME/.ssh/authorized_keys. El propietario de los directorios $HOME y $HOME/.ssh y del archivo $HOME/.ssh/authorized_keys debe ser el mismo que el usuario que se conecta a la VM.

      Permisos

      El entorno de invitado requiere los siguientes permisos de Linux:

      Ruta Permisos
      /home 0755
      $HOME 0700 o 0750 o 0755 *
      $HOME/.ssh 0700
      $HOME/.ssh/authorized_keys 0600

      * Para saber cuál es el permiso predeterminado correcto para tu directorio $HOME, consulta la documentación oficial de tu distribución de Linux.

      También puedes crear una VM a partir de la misma imagen y comprobar sus permisos predeterminados para $HOME.

      Para saber cómo cambiar los permisos y la propiedad, consulta los artículos sobre chmod y chown.

    • Reinicia el sshd ejecutando el siguiente comando:

      systemctl restart sshd.service

      Comprueba si hay algún error en el estado ejecutando el siguiente comando:

      systemctl status sshd.service

      La salida del estado puede contener información como el código de salida, el motivo del fallo, etc. Puedes usar estos detalles para seguir solucionando el problema.

  • La VM no se inicia y no puedes conectarte mediante SSH ni la consola en serie. Si no se puede acceder a la VM, es posible que tu SO esté dañado. Si el disco de arranque no arranca, puedes diagnosticar el problema. Si quieres recuperar la VM dañada y los datos, consulta Recuperar una VM dañada o un disco de arranque completo.

  • La VM se está iniciando en modo de mantenimiento. Cuando se inicia en modo de mantenimiento, la VM no acepta conexiones SSH, pero puedes conectarte a la consola serie de la VM e iniciar sesión como usuario raíz.

    Para solucionar este problema, sigue estos pasos:

    1. Si no has definido una contraseña de superusuario para la VM, usa una secuencia de comandos de inicio de metadatos para ejecutar el siguiente comando durante el arranque:

      echo 'root:NEW_PASSWORD' | chpasswd

      Sustituye NEW_PASSWORD por la contraseña que quieras.

    2. Reinicia la VM.

    3. Conéctate a la consola serie de la VM e inicia sesión como usuario root.

Error inesperado

Puede que se produzca el siguiente error al intentar conectarse a una VM Linux:

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

Este problema puede deberse a varios motivos. Estas son algunas de las causas habituales del error:

  • El daemon OpenSSH (sshd) no se está ejecutando o no se ha configurado correctamente. La sshd proporciona acceso remoto seguro al sistema mediante el protocolo SSH. Si está mal configurado o no se está ejecutando, no podrás conectarte a tu máquina virtual mediante SSH.

    Para solucionar este problema, prueba una o varias de las siguientes opciones:

    • Consulta la guía del usuario de tu sistema operativo para asegurarte de que tu sshd_config esté configurado correctamente.

    • Asegúrate de que tienes la propiedad y los permisos necesarios para lo siguiente:

      • Directorios $HOME y $HOME/.ssh
      • Archivo $HOME/.ssh/authorized_keys

      Propiedad

      El entorno de invitado almacena las claves públicas SSH autorizadas en el archivo $HOME/.ssh/authorized_keys. El propietario de los directorios $HOME y $HOME/.ssh y del archivo $HOME/.ssh/authorized_keys debe ser el mismo que el usuario que se conecta a la VM.

      Permisos

      El entorno de invitado requiere los siguientes permisos de Linux:

      Ruta Permisos
      /home 0755
      $HOME 0700 o 0750 o 0755 *
      $HOME/.ssh 0700
      $HOME/.ssh/authorized_keys 0600

      * Para saber cuál es el permiso predeterminado correcto para tu directorio $HOME, consulta la documentación oficial de tu distribución de Linux.

      También puedes crear una VM a partir de la misma imagen y comprobar sus permisos predeterminados para $HOME.

      Para saber cómo cambiar los permisos y la propiedad, consulta los artículos sobre chmod y chown.

    • Reinicia el sshd ejecutando el siguiente comando:

      systemctl restart sshd.service

      Comprueba si hay algún error en el estado ejecutando el siguiente comando:

      systemctl status sshd.service

      La salida del estado puede contener información como el código de salida, el motivo del fallo, etc. Puedes usar estos detalles para seguir solucionando el problema.

  • Problema desconocido del daemon SSH. Para diagnosticar un problema desconocido del daemon SSH, consulta los registros de la consola serie para ver si hay errores.

    En función de la salida de los registros de la consola en serie, intenta rescatar la VM y solucionar los problemas relacionados con el daemon SSH haciendo lo siguiente:

    1. Adjunta el disco a otra máquina virtual Linux.
    2. Conéctate a la VM que tiene el disco montado.
    3. Monta el disco en el SO en un directorio MOUNT_DIR de la VM.
    4. Consulta los registros relacionados con SSH, /var/log/secure o /var/log/auth.log, para ver si hay problemas o errores. Si detectas algún problema que puedas solucionar, intenta hacerlo. De lo contrario, crea un caso de asistencia y adjunta los registros.

    5. Desmonta el disco del SO con el comando umount:

      cd ~/
umount /mnt

    6. Desconecta el disco de la VM.

    7. Adjunta el disco a la VM original.

    8. Inicia la VM.

No se ha podido conectar con el backend

Pueden producirse los siguientes errores al conectarse a su VM desde la consolaGoogle Cloud o la CLI de gcloud:

  • La consola Google Cloud :

    -- Connection via Cloud Identity-Aware Proxy Failed

-- Code: 4003

-- Reason: failed to connect to backend

  • La CLI de gcloud:

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

Estos errores se producen cuando intentas usar SSH para conectarte a una VM que no tiene una dirección IP pública y en la que no has configurado Identity-Aware Proxy en el puerto 22.

Para solucionar este problema, crea una regla de cortafuegos en el puerto 22 que permita el tráfico de entrada de Identity-Aware Proxy.

La clave de host no coincide

Puede producirse el siguiente error al conectarte a tu VM:

Host key for server IP_ADDRESS does not match

Este error se produce cuando la clave de host del archivo ~/.ssh/known_hosts no coincide con la clave de host de la máquina virtual.

Para solucionar este problema, elimina la clave de host del archivo ~/.ssh/known_hosts y vuelve a intentar la conexión.

El valor de metadatos es demasiado grande

Puede que se produzca el siguiente error al intentar añadir una clave SSH a los metadatos:

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

Los valores de metadatos tienen un límite máximo de 256 KB. Para mitigar esta limitación, haz una de las siguientes acciones:

No hay métodos de autenticación admitidos disponibles

Puede producirse el siguiente error al conectarse a una VM:

No supported authentication methods available (server sent: publickey,gssapi-keyex,gssapi-with-mic)

Este error suele producirse debido a que el cliente SSH está obsoleto. Es posible que los clientes SSH antiguos no admitan los tipos de clave ECDSA y los algoritmos de cifrado SHA-2 que requieren las máquinas virtuales más recientes.

Por ejemplo, este error se produce si intentas conectarte a una VM de Red Hat Enterprise Linux (RHEL) con una versión de PuTTY anterior a la 0.75.

Para solucionar este error, actualiza tu cliente SSH a la versión estable más reciente. Después de actualizar el cliente SSH, vuelve a intentar la conexión SSH.

Errores de Windows

Permiso denegado. Inténtalo de nuevo.

Puede producirse el siguiente error al conectarte a tu VM:

USERNAME@compute.INSTANCE_ID's password:
Permission denied, please try again.

Este error indica que el usuario que intenta conectarse a la VM no existe en ella. Estas son algunas de las causas más habituales de este error:

  • Tu versión de gcloud CLI está desactualizada

    Si la CLI de gcloud no está actualizada, es posible que estés intentando conectarte con un nombre de usuario que no esté configurado. Para solucionar este problema, actualiza gcloud CLI.

  • Has intentado conectarte a una VM de Windows que no tiene habilitado SSH.

    Para resolver este error, asigna el valor TRUE a la clave enable-windows-ssh en los metadatos del proyecto o de la instancia. Para obtener más información sobre cómo definir metadatos, consulta Definir metadatos personalizados.

Permiso denegado (clave pública,interacción con el teclado)

Puede producirse el siguiente error al conectarse a una VM que no tiene habilitado SSH:

Permission denied (publickey,keyboard-interactive).

Para resolver este error, asigna el valor TRUE a la clave enable-windows-ssh en los metadatos del proyecto o de la instancia. Para obtener más información sobre cómo definir metadatos, consulta Definir metadatos personalizados.

No se ha podido conectar a la instancia mediante SSH

Puede que se produzca el siguiente error al conectarte a tu VM desde la CLI de gcloud:

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.

Este error puede deberse a varios motivos. A continuación, se indican algunas de las causas más habituales de los errores:

Se ha superado el tiempo de espera de conexión.

Las conexiones SSH que agotan el tiempo de espera pueden deberse a uno de los siguientes motivos:

  • La máquina virtual no ha terminado de iniciarse. Espera un poco a que se inicie la VM.

    Para solucionar este problema, espera a que la VM haya terminado de iniciarse e intenta conectarte de nuevo.

  • El paquete SSH no está instalado. En las VMs Windows, debes instalar el paquete google-compute-engine-ssh para poder conectarte mediante SSH.

    Para solucionar este problema, instala el paquete SSH.

Diagnosticar conexiones SSH fallidas

En las siguientes secciones se describen los pasos que puedes seguir para diagnosticar la causa de los errores de conexión SSH y para solucionar los problemas de conexión.

Antes de diagnosticar las conexiones SSH fallidas, completa los siguientes pasos:

Métodos de diagnóstico para máquinas virtuales Linux y Windows

Probar la conectividad

Es posible que no puedas conectarte a una instancia de VM mediante SSH debido a problemas de conectividad relacionados con cortafuegos, la conexión de red o la cuenta de usuario. Sigue los pasos de esta sección para identificar cualquier problema de conectividad.

Comprobar las reglas de cortafuegos

Compute Engine proporciona a cada proyecto un conjunto predeterminado de reglas de firewall que permiten el tráfico SSH. Si no puedes acceder a tu instancia, usa la herramienta de línea de comandos gcloud compute para consultar tu lista de cortafuegos y asegúrate de que la regla default-allow-ssh esté presente.

En tu estación de trabajo local, ejecuta el siguiente comando:

gcloud compute firewall-rules list

Si falta la regla de cortafuegos, vuelve a añadirla:

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

Para ver todos los datos asociados a la regla de cortafuegos default-allow-ssh de tu proyecto, usa el comando gcloud compute firewall-rules describe:

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

Para obtener más información sobre las reglas de cortafuegos, consulta Reglas de cortafuegos en Google Cloud.

Probar la conexión de red

Para determinar si la conexión de red funciona, prueba el handshake TCP:

  1. Obtén la natIP externa de tu máquina virtual:

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

    Sustituye VM_NAME por el nombre de la máquina virtual a la que no puedes conectarte.

  2. Prueba la conexión de red a tu VM desde tu estación de trabajo:

    Linux, Windows 2019/2022 y macOS 

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

    Haz los cambios siguientes:

    • EXTERNAL_IP: la dirección IP externa que has obtenido en el paso anterior
    • PORT_NUMBER: número de puerto

    Si la negociación TCP se realiza correctamente, el resultado será similar al siguiente:

    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 línea Connected to indica que el handshake TCP se ha realizado correctamente.

    Windows 2012 y 2016 

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

    Haz los cambios siguientes:

    • EXTERNAL_IP: la IP externa que has obtenido en el paso anterior
    • PORT_NUMBER: número de puerto

    Si la negociación TCP se realiza correctamente, el resultado será similar al siguiente:

    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 línea Connected: True indica que el handshake TCP se ha realizado correctamente.

Si la negociación TCP se completa correctamente, significa que una regla de cortafuegos de software no está bloqueando la conexión, que el SO está reenviando los paquetes correctamente y que un servidor está escuchando en el puerto de destino. Si la negociación TCP se completa correctamente, pero la VM no acepta conexiones SSH, puede que el problema se deba a que el daemon sshd no esté configurado correctamente o no se esté ejecutando de forma adecuada. Consulta la guía del usuario de tu sistema operativo para asegurarte de que tu sshd_config esté configurado correctamente.

Para ejecutar pruebas de conectividad para analizar la configuración de la ruta de la red VPC entre dos máquinas virtuales y comprobar si la configuración programada debería permitir el tráfico, consulta Comprobar si hay reglas de cortafuegos mal configuradas en Google Cloud.

Conectar como otro usuario

Es posible que el problema que te impide iniciar sesión solo afecte a tu cuenta de usuario. Por ejemplo, es posible que los permisos del archivo ~/.ssh/authorized_keys de la instancia no estén configurados correctamente para el usuario.

Prueba a iniciar sesión como otro usuario con gcloud CLI especificando ANOTHER_USERNAME con la solicitud SSH. La CLI de gcloud actualiza los metadatos del proyecto para añadir el nuevo usuario y permitir el acceso SSH.

gcloud compute ssh ANOTHER_USERNAME@VM_NAME

Haz los cambios siguientes:

  • ANOTHER_USERNAME es un nombre de usuario distinto al tuyo
  • VM_NAME es el nombre de la VM a la que quieres conectarte.

Depurar problemas con la consola de serie

Te recomendamos que revises los registros de la consola serie para detectar errores de conexión. Puedes acceder a la consola serie como usuario raíz desde tu estación de trabajo local mediante un navegador. Este método es útil cuando no puedes iniciar sesión con SSH o si la instancia no tiene conexión a la red. La consola serie sigue accesible en ambas situaciones.

Para iniciar sesión en la consola en serie de la VM y solucionar problemas con ella, sigue estos pasos::

  1. Habilita el acceso interactivo a la consola en serie de la VM.

  2. En el caso de las máquinas virtuales Linux, modifica la contraseña de root y añade la siguiente secuencia de comandos de inicio a tu máquina virtual: 

    echo root:PASSWORD | chpasswd

    Sustituye PASSWORD por la contraseña que quieras.

  3. Usa la consola en serie para conectarte a tu VM.

  4. En el caso de las máquinas virtuales Linux, cuando hayas terminado de depurar todos los errores, inhabilita el inicio de sesión de la cuenta raíz: 

    sudo passwd -l root

Métodos de diagnóstico para máquinas virtuales Linux

Inspeccionar la instancia de VM sin apagarla

Puede que tengas una instancia a la que no puedas conectarte, pero que siga sirviendo tráfico de producción correctamente. En este caso, puede que quieras inspeccionar el disco sin interrumpir la instancia.

Para inspeccionar el disco y solucionar los problemas que pueda tener, sigue estos pasos:

  1. Crea una copia de seguridad de tu disco de arranque creando una captura del disco.
  2. Crea un disco persistente normal a partir de esa captura.
  3. Crea una instancia temporal.
  4. Conecta y monta el disco persistente normal en tu nueva instancia temporal.

Este procedimiento crea una red aislada que solo permite conexiones SSH. Esta configuración evita que la instancia clonada interfiera en tus servicios de producción.

  1. Crea una red de VPC para alojar la instancia clonada:

    gcloud compute networks create debug-network

    Sustituye NETWORK_NAME por el nombre que quieras dar a tu nueva red.

  2. Añade una regla de cortafuegos para permitir las conexiones SSH a la red:

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

  3. Crea una captura del disco de arranque.

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

    Sustituye BOOT_DISK_NAME por el nombre del disco de arranque.

  4. Crea un disco con la instantánea que acabas de crear:

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

  5. Crea una instancia de depuración sin una dirección IP externa:

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

  6. Acopla el disco de depuración a la instancia:

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

  7. Sigue las instrucciones para conectarte a una VM mediante un host bastion.

  8. Una vez que hayas iniciado sesión en la instancia del depurador, soluciona los problemas de la instancia. Por ejemplo, puedes consultar los registros de la instancia:

    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

    Sustituye VM_NAME por el nombre de la máquina virtual a la que no puedes conectarte.

Usar una secuencia de comandos de inicio

Si nada de lo anterior te ha ayudado, puedes crear una secuencia de comandos de inicio para recoger información justo después de que se inicie la instancia. Sigue las instrucciones para ejecutar una secuencia de comandos de inicio.

Después, también debes restablecer la instancia para que los metadatos se apliquen. Para ello, usa gcloud compute instances reset.

También puedes volver a crear la instancia ejecutando una secuencia de comandos de inicio de diagnóstico:

  1. Ejecuta gcloud compute instances delete con la marca --keep-disks.

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

    Sustituye VM_NAME por el nombre de la máquina virtual a la que no puedes conectarte.

  2. Añade una instancia con el mismo disco y especifica tu secuencia de comandos de inicio.

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

    Haz los cambios siguientes:

    • NEW_VM_NAME es el nombre de la nueva VM que vas a crear.
    • BOOT_DISK_NAME es el nombre del disco de arranque de la máquina virtual a la que no puedes conectarte.
    • URL es la URL de Cloud Storage del script, en formato gs://BUCKET/FILE o https://storage.googleapis.com/BUCKET/FILE.

Usar el disco en una instancia nueva

Si sigues necesitando recuperar datos de tu disco de arranque persistente, puedes separar el disco de arranque y, a continuación, adjuntarlo como disco secundario en una instancia nueva.

  1. Elimina la máquina virtual a la que no puedes conectarte y conserva su disco de arranque:

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

    Sustituye VM_NAME por el nombre de la máquina virtual a la que no puedes conectarte.

  2. Crea una VM con el disco de arranque de la VM anterior. Especifica el nombre del disco de arranque de la VM que acabas de eliminar.

  3. Conéctate a tu nueva VM mediante SSH:

    gcloud compute ssh NEW_VM_NAME

    Sustituye NEW_VM_NAME por el nombre de tu nueva VM.

Comprobar si el disco de arranque de la VM está lleno

Es posible que no puedas acceder a tu VM si su disco de arranque está lleno. En este caso, puede ser difícil solucionar el problema, ya que no siempre es evidente que el problema de conectividad de la VM se debe a que el disco de arranque está lleno. Para obtener más información sobre este caso, consulta Solucionar problemas de una máquina virtual a la que no se puede acceder porque el disco de arranque está lleno.

Métodos de diagnóstico para máquinas virtuales Windows

Restablecer metadatos de SSH

Si no puedes conectarte a una VM de Windows mediante SSH, prueba a quitar la clave de metadatos enable-windows-ssh y a volver a habilitar SSH para Windows.

  1. Define la clave de metadatos enable-windows-ssh en FALSE. Para obtener información sobre cómo definir metadatos, consulta Definir metadatos personalizados.

    Espera unos segundos a que se aplique el cambio.

  2. Volver a habilitar SSH para Windows

  3. Vuelve a conectarte a la VM.

Conectarse a la VM mediante RDP

Si no puedes diagnosticar y resolver la causa de los errores de conexión SSH a tu máquina virtual Windows, conéctate mediante RDP.

Una vez que hayas establecido una conexión con la VM, consulta los registros de OpenSSH.

¿Qué debo hacer ahora?