Soluciona problemas de errores de SSH.

En este documento, se describen los errores comunes que puedes encontrar cuando te conectas a instancias de máquina virtual (VM) con SSH, formas de resolver errores y métodos para diagnosticar conexiones SSH con errores.

Herramienta de solución de problemas de SSH

Usa la herramienta de solución de problemas de SSH para determinar por qué falló la conexión SSH. La herramienta de solución de problemas realiza las siguientes pruebas para verificar la causa de las conexiones SSH con errores:

  • Pruebas de permisos del usuario: Verifica si tienes los permisos de IAM 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: Verifica el estado de la CPU de la VM para ver si la VM se está ejecutando.
  • Pruebas de configuración de VPC: Verifica el puerto SSH predeterminado.

Ejecuta la herramienta de solución de problemas

Puedes usar la consola de Google Cloud o Google Cloud CLI para comprobar si hay problemas de red y errores de permisos del usuario que podrían hacer que las conexiones SSH fallen.

Console

Después de que falla una conexión SSH, tienes la opción de Volver a conectarte o solucionar problemas de la conexión 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 de solución de problemas de SSH.

gcloud

Ejecuta la herramienta de solución de problemas mediante el comando gcloud compute ssh:

gcloud compute ssh VM_NAME \
    --troubleshoot

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

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

Revisa los resultados

Después de ejecutar la herramienta de solución de problemas, haz lo siguiente:

  1. Revisa los resultados de la prueba para comprender por qué la conexión SSH de la VM no funciona.
  2. Resuelve conexiones SSH mediante la realización de los pasos de solución que proporciona la herramienta.

  3. Intenta volver a conectarte a la VM.

    Si la conexión no se hace de forma correcta, intenta solucionar el problema de forma manual con los siguientes pasos:

Errores de SSH comunes

Los siguientes son ejemplos de errores comunes que puedes encontrar cuando usas SSH para conectarte a las VMs de Compute Engine.

Errores de SSH en el navegador

Error de autorización 401

El siguiente error puede ocurrir cuando te conectas a tu VM con el SSH en el navegador desde la consola de Google Cloud:

Unauthorized
Error 401

Este error se produce si el usuario es parte de una organización administrada 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 de serie dentro de Google Cloud.

Para resolver este problema, pídele a una persona perteneciente a la administración de Google Workspace que haga lo siguiente:

  1. Confirma que Google Cloud esté habilitado para la organización.

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

  2. Confirma que estén habilitados los servicios que no se controlan de forma individual.

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

Si el problema persiste después de habilitar la configuración de Google Cloud en Google Workspace, haz lo siguiente:

  1. Captura el tráfico de red en un archivo de formato de archivo HTTP (HAR) a partir del momento en que inicias la conexión SSH en el navegador.

  2. Crea un caso de Atención al cliente de Cloud y adjunta el archivo HAR.

No se pudo establecer una conexión. Intentaremos nuevamente...

El siguiente error puede ocurrir cuando inicias una sesión SSH: 

Could not connect, retrying ...

No se pudo establecer una conexión. Intentaremos nuevamente

Para solucionar este problema, haz lo siguiente:

  1. Cuando la VM termina de iniciarse, vuelve a intentar la conexión. Si la conexión no se hace de forma correcta, ejecuta el siguiente comando para verificar que la VM no se haya iniciado en modo de emergencia:

    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 dónde falla el proceso de inicio.

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

    systemctl status google-guest-agent.service

    Si el servicio está inhabilitado, ejecuta los siguientes comandos para habilitar y, luego, iniciar el servicio:

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

  3. Verifica que las secuencias de comandos del Agente de Google para Linux estén instaladas y en ejecución. Para obtener más información, consulta Determinación del estado del agente de Google. Si el Agente de Google de Linux no está instalado, vuelve a instalarlo.

  4. Verifica que tengas los roles necesarios para conectarte a la VM. Si tu VM usa el Acceso al SO, consulta Asigna el rol de IAM de Acceso al SO. Si la VM no usa el Acceso al SO, necesitas el rol de administrador de instancias de procesamiento o la rol del usuario de la cuenta de servicio (si la VM está configurada para ejecutarse como una cuenta de servicio). Los roles son necesarios para actualizar los metadatos de la clave SSH de la instancia o del proyecto.

  5. Ejecuta el siguiente comando para verificar que haya una regla de firewall que permita el acceso SSH:

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

  6. Verifica que haya una ruta predeterminada a Internet (o al host de bastión). Para obtener más información, consulta Cómo verificar rutas.

  7. Asegúrate de que el volumen raíz no se quede sin espacio en el disco. Para obtener más información, consulta Soluciona problemas de discos completos y cambio de tamaño de discos.

  8. Ejecuta el siguiente comando para asegurarte de que la VM no se haya quedado sin memoria:

    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 quedó sin memoria, conéctate a la consola en serie para solucionar el problema.

Errores de Linux

Permiso denegado (publickey)

El siguiente error se puede generar cuando te conectas a tu VM:

USERNAME@VM_EXTERNAL_IP: Permission denied (publickey).

Este error se puede generar por varios motivos. Las siguientes son algunas de las causas más comunes de este error:

  • Usaste una Llave SSH almacenada en metadatos para conectarte a una VM que tiene el acceso al SO habilitado. Si el acceso al SO está habilitado en tu proyecto, la VM no acepta Llaves SSH almacenadas en metadatos. Si no estás seguro de si el Acceso al SO está habilitado, consulta Verifica si el Acceso al SO está configurado.

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

  • Usaste una clave SSH almacenada en un perfil de acceso al SO para conectarte a una VM que no tiene acceso al SO habilitado. Si inhabilitas el acceso al SO, tu VM no acepta claves SSH que se almacenaron en tu perfil del acceso al SO. Si no estás seguro de si el Acceso al SO está habilitado, consulta Verifica si el Acceso al SO está configurado.

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

  • La VM tiene habilitado el Acceso al SO, pero no tienes suficientes permisos de IAM para usarlo. Si deseas conectarte a una VM que tiene el Acceso al SO habilitado, debes tener los permisos necesarios para este. Si no estás seguro de si el Acceso al SO está habilitado, consulta Verifica si el Acceso al SO está configurado.

    Para resolver este problema, otorga los roles de IAM de Acceso al SO necesarios.

  • Tu clave caducó y Compute Engine borró tu archivo ~/.ssh/authorized_keys. Si agregas claves SSH de forma manual a tu VM y, luego, te conectas a tu VM mediante la consola de Google Cloud, Compute Engine crea un nuevo par de claves para tu conexión. Después de que el par de claves nuevo vence, Compute Engine borra tu archivo ~/.ssh/authorized_keys en la VM, que incluye tu clave SSH agregada de forma manual.

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

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

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

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

      Reemplaza lo siguiente:
      • PATH_TO_PRIVATE_KEY: Es la ruta de acceso al archivo de clave SSH privada.
      • USERNAME: El nombre de usuario del usuario que se conecta a la instancia. Si administras las claves SSH en metadatos, el nombre de usuario es el que especificaste cuando creaste la clave SSH. En el caso de las cuentas de acceso al SO, el nombre de usuario se define en tu perfil de Google.
      • EXTERNAL_IP: La dirección IP externa de la VM.
    • Conéctate a la VM mediante la consola de Google Cloud o Google Cloud CLI. Cuando usas estas herramientas para conectarte, Compute Engine administra la creación de claves por ti. Para obtener más información, consulta Conéctate a instancias de VM.

  • El entorno invitado de tu VM no está en ejecución. Si es la primera vez que te conectas a la VM y el entorno invitado no se ejecuta, es posible que la VM rechace la solicitud de conexión SSH.

    Para solucionar este problema, haz lo siguiente:

    1. Reinicia la VM.
    2. En la consola de Google Cloud, inspecciona los registros de inicio del sistema en la salida del puerto en serie para determinar si el entorno invitado se está ejecutando. Para obtener más información, consulta Valida el entorno invitado.
    3. Si el entorno invitado no se ejecuta, clona el disco de arranque de la VM y usa una secuencia de comandos de inicio para instalarlo de forma manual.

  • El daemon de OpenSSH (sshd) no se ejecuta ni está configurado de forma correcta. El sshd proporciona acceso remoto seguro al sistema a través del protocolo SSH. Si está mal configurada o no está en ejecución, no puedes conectarte a la VM a través de SSH.

    Para resolver este problema, prueba una o más de las siguientes opciones:

    • Revisa la guía del usuario del sistema operativo para asegurarte de que tu sshd_config esté configurado de forma correcta.

    • Asegúrate de tener la configuración de propiedad y de permiso requerida para los siguientes elementos:

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

      Propiedad

      El entorno 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 el archivo $HOME/.ssh/authorized_keys debe ser el mismo que el usuario que se conecta a la VM.

      Permisos

      El entorno 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

      * A fin de averiguar cuál de las opciones es el permiso predeterminado correcto para tu directorio $HOME, consulta la documentación oficial de tu distribución específica de Linux.

      Como alternativa, puedes crear una VM nueva basada en la misma imagen y verificar sus permisos predeterminados para $HOME.

      Si quieres obtener información para cambiar los permisos y la propiedad, consulta chmod y chown.

    • Reinicia el sshd mediante la ejecución del siguiente comando:

      systemctl restart sshd.service

      Ejecuta el siguiente comando para verificar si hay errores en el estado:

      systemctl status sshd.service

      El resultado del estado puede contener información como el código de salida, el motivo de la falla, etc. Puedes usar estos detalles para solucionar problemas adicionales.

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

    Para resolver este problema, realiza una o más de las siguientes acciones:

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

    Propiedad

    El entorno 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 el archivo $HOME/.ssh/authorized_keys debe ser el mismo que el usuario que se conecta a la VM.

    Permisos

    El entorno 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

    * A fin de averiguar cuál de las opciones es el permiso predeterminado correcto para tu directorio $HOME, consulta la documentación oficial de tu distribución específica de Linux.

    Como alternativa, puedes crear una VM nueva basada en la misma imagen y verificar sus permisos predeterminados para $HOME.

    Si quieres obtener información para cambiar los permisos y la propiedad, consulta chmod y chown.

No se pudo establecer la conexión

Los siguientes errores pueden ocurrir cuando te conectas a tu VM desde la consola de Google Cloud, gcloud CLI, un host de bastión o un cliente local:

  • La consola de Google Cloud:

    Connection Failed

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

  • La gcloud CLI:

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

  • Un host de bastión o un cliente local:

    port 22: Connection timed out.

    port 22: Connection refused

Estos errores pueden ocurrir por varios motivos. Las siguientes son algunas de las causas más comunes de los errores:

  • La VM se inicia y sshd aún no se ejecuta. No puedes conectarte a una VM antes de que se ejecute.

    Para resolver este problema, espera hasta que la VM termine de iniciarse e intenta conectarte de nuevo.

  • sshd se ejecuta en un puerto personalizado. Si configuraste sshd para que se ejecute en un puerto distinto del puerto 22, no podrás conectarte a la VM.

    Para resolver este problema, crea una regla de firewall personalizada que permita el tráfico tcp en el puerto en el que se ejecuta 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 firewall personalizadas, consulta Crea reglas de firewall.

  • Falta la regla de firewall SSH o no permite el tráfico de IAP o el Internet público. Las conexiones SSH se rechazan si las reglas de firewall no permiten conexiones desde el tráfico de entrada de IAP o TCP para el rango de IP 0.0.0.0/0.

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

    • Si usas Identity-Aware Proxy (IAP) para la redirección de TCP, actualiza tu regla de firewall personalizada a fin de aceptar tráfico de IAP y, luego, verifica los permisos de IAM.

      1. Actualiza tu regla de firewall personalizada a fin de permitir el tráfico desde 35.235.240.0/20, el rango de direcciones IP que IAP usa para el reenvío de TCP. Si deseas obtener más información, consulta Crea una regla de firewall.
      2. Otorga permisos para usar el reenvío IAP de TCP, si aún no lo hiciste.

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

      1. Actualiza tu regla de firewall personalizada para Permitir las conexiones SSH de entrada a las VMs.

  • La conexión SSH falló después de actualizar el kernel de la VM. Una VM puede experimentar un error irrecuperable del kernel después de una actualización del kernel, lo que hace que la VM se vuelva inaccesible.

    Para solucionar este problema, haz lo siguiente:

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

    De forma alternativa, si creaste una instantánea del disco de arranque antes de actualizar la VM, usa la instantánea para crear una VM.

  • El daemon de OpenSSH (sshd) no se ejecuta ni está configurado de forma correcta. El sshd proporciona acceso remoto seguro al sistema a través del protocolo SSH. Si está mal configurada o no está en ejecución, no puedes conectarte a la VM a través de SSH.

    Para resolver este problema, prueba una o más de las siguientes opciones:

    • Revisa la guía del usuario del sistema operativo para asegurarte de que tu sshd_config esté configurado de forma correcta.

    • Asegúrate de tener la configuración de propiedad y de permiso requerida para los siguientes elementos:

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

      Propiedad

      El entorno 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 el archivo $HOME/.ssh/authorized_keys debe ser el mismo que el usuario que se conecta a la VM.

      Permisos

      El entorno 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

      * A fin de averiguar cuál de las opciones es el permiso predeterminado correcto para tu directorio $HOME, consulta la documentación oficial de tu distribución específica de Linux.

      Como alternativa, puedes crear una VM nueva basada en la misma imagen y verificar sus permisos predeterminados para $HOME.

      Si quieres obtener información para cambiar los permisos y la propiedad, consulta chmod y chown.

    • Reinicia el sshd mediante la ejecución del siguiente comando:

      systemctl restart sshd.service

      Ejecuta el siguiente comando para verificar si hay errores en el estado:

      systemctl status sshd.service

      El resultado del estado puede contener información como el código de salida, el motivo de la falla, etc. Puedes usar estos detalles para solucionar problemas adicionales.

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

  • La VM se inicia en modo de mantenimiento. Cuando se inicia en modo de mantenimiento, la VM no acepta conexiones SSH, pero puedes conectarte a la consola en serie de la VM y acceder como el usuario raíz.

    Para solucionar este problema, haz lo siguiente:

    1. Si no configuraste una contraseña raíz para la VM, usa una secuencia de comandos de inicio de metadatos a fin de ejecutar el siguiente comando durante el inicio:

      echo "root:NEW_PASSWORD" | chpasswd

      Reemplaza NEW_PASSWORD por una contraseña de tu elección.

    2. Reinicia la VM.

    3. Conéctate a la consola en serie de la VM y accede como el usuario raíz.

Error inesperado

El siguiente error puede ocurrir cuando intentas conectarte a una VM de Linux:

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

Este error se puede generar por varios motivos. Las siguientes son algunas causas comunes del error:

  • El daemon de OpenSSH (sshd) no se ejecuta ni está configurado de forma correcta. El sshd proporciona acceso remoto seguro al sistema a través del protocolo SSH. Si está mal configurada o no está en ejecución, no puedes conectarte a la VM a través de SSH.

    Para resolver este problema, prueba una o más de las siguientes opciones:

    • Revisa la guía del usuario del sistema operativo para asegurarte de que tu sshd_config esté configurado de forma correcta.

    • Asegúrate de tener la configuración de propiedad y de permiso requerida para los siguientes elementos:

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

      Propiedad

      El entorno 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 el archivo $HOME/.ssh/authorized_keys debe ser el mismo que el usuario que se conecta a la VM.

      Permisos

      El entorno 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

      * A fin de averiguar cuál de las opciones es el permiso predeterminado correcto para tu directorio $HOME, consulta la documentación oficial de tu distribución específica de Linux.

      Como alternativa, puedes crear una VM nueva basada en la misma imagen y verificar sus permisos predeterminados para $HOME.

      Si quieres obtener información para cambiar los permisos y la propiedad, consulta chmod y chown.

    • Reinicia el sshd mediante la ejecución del siguiente comando:

      systemctl restart sshd.service

      Ejecuta el siguiente comando para verificar si hay errores en el estado:

      systemctl status sshd.service

      El resultado del estado puede contener información como el código de salida, el motivo de la falla, etc. Puedes usar estos detalles para solucionar problemas adicionales.

  • Problema de daemon SSH desconocido. Para diagnosticar un problema de daemon SSH desconocido, revisa los registros de la consola en serie para detectar errores.

    Según el resultado de los registros de la consola en serie, intenta recuperar la VM y solucionar los problemas relacionados con el daemon de SSH mediante lo siguiente:

    1. Conecta el disco a otra VM de Linux.
    2. Conéctate a la VM que tiene el disco activado.
    3. Activa el disco dentro del SO en un directorio MOUNT_DIR dentro 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 ves algún problema que puedes corregir, intenta solucionarlos. De lo contrario, crea un caso de asistencia y adjunta los registros.

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

      cd ~/
umount /mnt

    6. Desconecta el disco de la VM.

    7. Conecta el disco a la VM original.

    8. Inicia la VM.

No se pudo establecer una conexión con el backend

Los siguientes errores pueden ocurrir cuando te conectas a tu VM desde la consola de Google Cloud o la gcloud CLI:

  • La consola de Google Cloud:

    -- Connection via Cloud Identity-Aware Proxy Failed

-- Code: 4003

-- Reason: failed to connect to backend

  • La gcloud CLI:

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

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

Para resolver este problema, crea una regla de firewall en el puerto 22 que permite el tráfico de entrada desde Identity-Aware Proxy.

La clave de host no coincide

El siguiente error se puede generar cuando te conectas 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 VM.

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

El valor de metadatos es demasiado grande

El siguiente error puede ocurrir cuando intentas agregar una clave SSH nueva 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, realiza una de las siguientes acciones:

Errores de Windows

Permiso denegado. Vuelve a intentarlo.

El siguiente error se puede generar cuando te conectas 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 la VM. Las siguientes son algunas de las causas más comunes de este error:

  • Tu versión de la gcloud CLI está desactualizada

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

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

    Para resolver este error, establece la clave enable-windows-ssh en TRUE en los metadatos del proyecto o de la instancia. Para obtener más información sobre la configuración de los metadatos, consulta Establece metadatos personalizados.

Permiso denegado (publickey,keyboard-interactive)

El siguiente error puede ocurrir cuando te conectas a una VM que no tiene SSH habilitado:

Permission denied (publickey,keyboard-interactive).

Para resolver este error, establece la clave enable-windows-ssh en TRUE en los metadatos del proyecto o de la instancia. Para obtener más información sobre la configuración de los metadatos, consulta Establece metadatos personalizados.

No se pudo establecer una conexión SSH a la instancia

El siguiente error puede ocurrir cuando te conectas a tu VM desde la gcloud CLI:

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 se puede generar por varios motivos. Las siguientes son algunas de las causas más comunes de los errores:

  • Intentaste conectarte a una VM de Windows que no tiene instalado SSH.

    A fin de resolver este problema, sigue las instrucciones sobre cómo habilitar SSH para Windows en una VM en ejecución.

  • El servidor OpenSSH (sshd) no está en ejecución o no está configurado de forma correcta. El sshd proporciona acceso remoto seguro al sistema a través del protocolo SSH. Si está mal configurada o no está en ejecución, no puedes conectarte a la VM a través de SSH.

    Para resolver este problema, revisa la configuración de OpenSSH Server para Windows Server y Windows así podrás asegurarte de que sshd esté configurado de forma correcta.

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

Las conexiones SSH con tiempo de espera agotado pueden deberse a una de las siguientes causas:

  • La VM no terminó de iniciarse. Espera un momento hasta que la VM se inicie.

    Para resolver este problema, espera hasta que la VM termine de iniciarse e intenta conectarte de nuevo.

  • El paquete SSH no está instalado. Las VM de Windows requieren que instales el paquete google-compute-engine-ssh antes de poder conectarte mediante SSH.

    Para resolver este problema, instala el paquete SSH.

Diagnostica conexiones SSH con errores

En las siguientes secciones, se describen los pasos que puedes seguir a fin de diagnosticar la causa de conexiones SSH con errores y los pasos que puedes seguir para corregir las conexiones.

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

Métodos de diagnóstico para VM de Linux y Windows

Prueba la conectividad

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

Verifica las reglas de firewall

Compute Engine aprovisiona cada proyecto con un conjunto predeterminado de reglas de firewall que permiten el tráfico SSH. Si no puedes acceder a la instancia, usa la herramienta de línea de comandos de gcloud compute para verificar la lista de firewalls y asegurarte de que la regla default-allow-ssh está presente.

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

gcloud compute firewall-rules list

Si falta la regla de firewall, agrégala de nuevo:

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

Para ver todos los datos asociados a la regla de firewall default-allow-ssh en el 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 firewall, consulta las Reglas de firewall en Google Cloud.

Prueba la conexión de red

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

  1. Obtén el natIP externo para tu VM:

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

    Reemplaza VM_NAME por el nombre de la VM 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

    Reemplaza lo siguiente:

    • EXTERNAL_IP: la dirección IP externa que obtuviste en el paso anterior
    • PORT_NUMBER es el número de puerto.

    Si el protocolo de enlace TCP se ejecuta de forma correcta, el resultado es 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 un protocolo de enlace TCP correcto.

    Windows 2012 y 2016 

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

    Reemplaza lo siguiente:

    • EXTERNAL_IP: la IP externa que obtuviste en el paso anterior
    • PORT_NUMBER es el número de puerto.

    Si el protocolo de enlace TCP se ejecuta de forma correcta, el resultado es 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 un protocolo de enlace TCP correcto.

Si el protocolo de enlace TCP se completa de forma correcta, una regla de firewall de software no bloquea la conexión, el SO reenvía los paquetes correctamente y un servidor escucha en el puerto de destino. Si el protocolo de enlace TCP se completa de forma correcta, pero la VM no acepta conexiones SSH, el problema puede ser que el daemon sshd está mal configurado o no se ejecuta de forma correcta. Revisa la guía del usuario del sistema operativo para asegurarte de que tu sshd_config esté configurado de forma correcta.

Para ejecutar pruebas de conectividad para analizar la configuración de la ruta de red de VPC entre dos VM y verificar si la configuración programada debe permitir el tráfico, consulta Verifica las reglas de firewall mal configuradas en Google Cloud.

Conéctate como un usuario diferente

El problema que impide el acceso puede estar limitado a tu cuenta de usuario. Por ejemplo, es posible que los permisos del archivo ~/.ssh/authorized_keys en la instancia no estén configurados correctamente para el usuario.

Intenta acceder como otro usuario con la CLI de gcloud. Para ello, especifica ANOTHER_USERNAME con la solicitud SSH. La gcloud CLI actualizará los metadatos del proyecto a fin de agregar el usuario nuevo y permitir el acceso SSH.

gcloud compute ssh ANOTHER_USERNAME@VM_NAME

Reemplaza lo siguiente:

  • ANOTHER_USERNAME es un nombre de usuario que no es tu propio nombre de usuario.
  • VM_NAME es el nombre de la VM a la que deseas conectarte.

Depura problemas con la consola en serie

Te recomendamos revisar los registros de la consola en serie para detectar errores de conexión. Puedes acceder a la consola en serie como el usuario raíz de tu estación de trabajo local mediante un navegador. Este enfoque es útil cuando no puedes acceder con SSH o si la instancia no tiene conexión a la red. La consola en serie permanece accesible en ambas situaciones.

Para acceder a la consola en serie de la VM y solucionar problemas de la VM, sigue estos pasos:

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

  2. Para las VM de Linux, modifica la contraseña raíz y agrega la siguiente secuencia de comandos de inicio a la VM: 

    echo root:PASSWORD | chpasswd

    Reemplaza PASSWORD por una contraseña de tu elección.

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

  4. Para las VM de Linux, una vez que hayas terminado de depurar todos los errores, inhabilita el acceso a la cuenta raíz: 

    sudo passwd -l root

Métodos de diagnóstico para VM de Linux

Inspecciona la instancia de VM sin cerrarla

Es posible que tengas una instancia a la que no puedas conectarte que siga entregando tráfico de producción de forma correcta. En este caso, se recomienda inspeccionar el disco sin interrumpir la instancia.

Para inspeccionar y solucionar problemas en el disco, sigue estos pasos:

  1. Crea una copia de seguridad de tu disco de arranque. Para ellos, crea una instantánea del disco.
  2. Crea un disco persistente regular a partir de esa instantánea.
  3. Crea una instancia temporal.
  4. Conecta y activa el disco persistente regular a la instancia temporal nueva.

En este procedimiento, se crea una red aislada que solo permite conexiones SSH. Esta configuración evita que cualquier consecuencia no deseada de la instancia clonada interfiera en los servicios de producción.

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

    gcloud compute networks create debug-network

    Reemplaza NETWORK_NAME por el nombre que deseas para tu red nueva.

  2. Agrega una regla de firewall para permitir conexiones SSH a la red:

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

  3. Crea una instantánea del disco de arranque.

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

    Reemplaza BOOT_DISK_NAME por el nombre del disco de arranque.

  4. Crea un disco nuevo 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 nueva sin una dirección IP externa:

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

  6. Adjunta 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 de bastión.

  8. Después de acceder a la instancia del depurador, soluciona los problemas de la instancia. Por ejemplo, puedes ver los registros de instancias:

    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

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

Usa una secuencia de comandos de inicio

Si nada de lo anterior te ayudó, puedes crear una secuencia de comandos de inicio para recopilar información justo después de que comience la instancia. Sigue las instrucciones para ejecutar una secuencia de comandos de inicio.

Luego, también debes restablecer tu instancia con gcloud compute instances reset para que los metadatos surtan efecto.

Como alternativa, puedes volver a crear la instancia si ejecutas 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

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

  2. Agrega una instancia nueva con el mismo disco y especifica la secuencia de comandos de inicio.

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

    Reemplaza lo siguiente:

    • NEW_VM_NAME es el nombre de la nueva VM que creas.
    • BOOT_DISK_NAME es el nombre del disco de arranque de la VM a la que no puedes conectarte.
    • URL es la URL de Cloud Storage a la secuencia de comandos, en formato gs://BUCKET/FILE o https://storage.googleapis.com/BUCKET/FILE.

Usa el disco en una instancia nueva

Si aún necesitas recuperar datos del disco de arranque persistente, puedes desconectarlo y, luego, conectarlo como disco secundario en una instancia nueva.

  1. Borra la VM a la que no puedes conectarte y mantén su disco de arranque:

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

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

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

  3. Conéctate a la VM nueva mediante SSH.

    gcloud compute ssh NEW_VM_NAME

    Reemplaza NEW_VM_NAME por el nombre de tu nueva VM.

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

Es posible que no se pueda acceder a tu VM si su disco de arranque está lleno. Esta situación puede ser difícil de solucionar, ya que no siempre es evidente cuándo el problema de conectividad de VM se debe a un disco de arranque completo. Para obtener más información sobre esta situación, consulta Soluciona problemas de una VM que es inaccesible debido a un disco de arranque completo.

Métodos de diagnóstico para VM de Windows

Restablece metadatos de SSH

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

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

    Espera unos segundos a que se realice el cambio.

  2. Vuelve a habilitar SSH para Windows

  3. Vuelve a conectarte a la VM.

Conéctate a la VM mediante RDP

Si no puedes diagnosticar y resolver la causa de las conexiones SSH con errores a tu VM de Windows, conéctate mediante RDP.

Después de establecer una conexión con la VM, revisa los registros de OpenSSH.

Cómo depurar problemas de SSH con gcpdiag

gcpdiag es una herramienta de código abierto. No es un producto de Google Cloud compatible oficialmente. Puedes usar la herramienta gcpdiag para identificar y corregir problemas del proyecto de Google Cloud. Para obtener más información, consulta el proyecto en GitHub.

En este runbook de gcpdiag, se investigan las posibles causas de los problemas de conexión SSH en las VMs de Windows y Linux en Google Cloud. Para ello, se examinan las siguientes áreas:
  • Estado de la VM: Comprueba si la VM se está ejecutando y tiene recursos suficientes (CPU, memoria, almacenamiento en disco).
  • Permisos: Garantiza los permisos de IAM correctos para configurar Llaves SSH.
  • Configuración de VM: Verifica que las claves SSH y otros metadatos estén configurados de forma correcta.
  • Reglas de red: Revisa las reglas de firewall para confirmar que el tráfico SSH está permitido.
  • SO invitado: Busca problemas internos del SO que podrían bloquear SSH.

Consola de Google Cloud

  1. Completa y, luego, copia el siguiente comando. 
    2. 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
  2. Abre la consola de Google Cloud y activa Cloud Shell.
    3. Abre la consola de Cloud
  3. Pega el comando copiado.
  4. Ejecuta el comando gcpdiag, que descarga la imagen de Docker gcpdiag y, luego, realiza verificaciones de diagnóstico. Si corresponde, sigue las instrucciones de salida para corregir las verificaciones que fallaron.

Docker

Puedes ejecutar gcpdiag con un wrapper que inicie gcpdiag en un contenedor de Docker. Se debe instalar Docker o Podman.

  1. Copia y ejecuta el siguiente comando en tu estación de trabajo local. 
    curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
  2. Ejecuta el 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

Consulta los parámetros disponibles para este runbook.

Reemplaza lo siguiente:

  • PROJECT_ID: Es el ID del proyecto que contiene el recurso.
  • VM_NAME: Es el nombre de la VM de destino dentro de tu proyecto.
  • ZONE: Es la zona en la que se encuentra la VM de destino.
  • PRINCIPAL: La principal de la cuenta de servicio o usuario que inicia la conexión SSH. Para la autenticación basada en claves, usa el usuario autenticado por tu herramienta de línea de comandos de Cloud Shell o que accedió a la consola de Google Cloud. Para la identidad temporal como cuenta de servicio, usa el correo electrónico de la cuenta de servicio.
  • IAP_ENABLED: Un valor booleano (verdadero o falso) que indica si se usa Identity-Aware Proxy para establecer la conexión SSH. Predeterminada: true
  • OS_LOGIN_ENABLED: un valor booleano (verdadero o falso) que indica si el Acceso al SO se usa para la autenticación SSH. Predeterminada: true

Marcas útiles:

  • --project: El PROJECT_ID
  • --universe-domain: Si corresponde, el dominio de Trusted Partner Sovereign Cloud que aloja el recurso
  • --parameter o -p: Parámetros del libro de ejecución

Para obtener una lista y una descripción de todas las marcas de la herramienta gcpdiag, consulta las instrucciones de uso de gcpdiag.

Próximos pasos