Solución de problemas de errores SSH

Este documento describe errores comunes que puede encontrar al conectarse a instancias de máquinas virtuales (VM) mediante SSH, formas de resolver errores y métodos para diagnosticar conexiones SSH fallidas.

Herramienta de resolución de problemas de SSH

Utilice la herramienta de solución de problemas de SSH para ayudar a determinar por qué falló una conexión SSH. La herramienta de solución de problemas realiza las siguientes pruebas para verificar la causa de las conexiones SSH fallidas:

  • Pruebas de permisos de usuario: comprueba si tiene los permisos de IAM necesarios para conectarse a la VM mediante SSH.
  • Pruebas de conectividad de red: comprueba si la VM está conectada a la red.
  • Pruebas de estado de instancia de VM: verifica el estado de la CPU de la VM para ver si se está ejecutando.
  • Pruebas de configuración de VPC: comprueba el puerto SSH predeterminado.

Ejecute la herramienta de solución de problemas

Puede utilizar la consola de Google Cloud 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

Después de que falla una conexión SSH, tiene la opción de Reintentar la conexión o Solucionar problemas de conexión utilizando la herramienta de solución de problemas SSH en el navegador.

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

Inicie la herramienta de solución de problemas de SSH.

nube de gcloud

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

gcloud compute ssh VM_NAME \
    --troubleshoot

Reemplace VM_NAME con el nombre de la VM a la que no puede conectarse.

La herramienta le solicita que proporcione permiso para realizar las pruebas de solución de problemas.

Revisa los resultados

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

  1. Revise los resultados de la prueba para comprender por qué la conexión SSH de la máquina virtual no funciona.
  2. Resuelva las conexiones SSH realizando los pasos de reparación proporcionados por la herramienta.

  3. Intente volver a conectarse a la VM.

    Si la conexión no se realiza correctamente, intente solucionar el problema manualmente haciendo lo siguiente:

Errores comunes de SSH

Los siguientes son ejemplos de errores comunes que puedes encontrar cuando usas SSH para conectarte a máquinas virtuales de Compute Engine.

Errores de SSH en el navegador

Error no autorizado 401

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

Unauthorized
Error 401

Este error ocurre si su 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 serie dentro. Google Cloud.

Para resolver este problema, pídale a un administrador de Google Workspace que haga lo siguiente:

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

    Si Google Cloud está deshabilitado, actívelo y vuelva a intentar la conexión.

  2. Confirme que los servicios que no se controlan individualmente estén habilitados.

    Si estos servicios están deshabilitados, habilítelos y vuelva a intentar la conexión.

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

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

  2. Cree un caso de Atención al cliente en la nube y adjunte el archivo HAR.

No se pudo conectar, reintentando...

El siguiente error puede ocurrir al iniciar una sesión SSH:

Could not connect, retrying ...

No se pudo conectar, reintentando

Para resolver este problema, haga lo siguiente:

  1. Una vez que la máquina virtual haya terminado de iniciarse, vuelva a intentar la conexión. Si la conexión no es exitosa, verifique 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 máquina virtual arranca en modo de emergencia, solucione los problemas del proceso de inicio de la máquina virtual para identificar dónde falla el proceso de arranque.

  2. Verifique que el servicio google-guest-agent.service se esté ejecutando ejecutando el siguiente comando en la consola serie .

    systemctl status google-guest-agent.service

    Si el servicio está deshabilitado, habilítelo e inícielo ejecutando los siguientes comandos:

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

  3. Verifique que los scripts del Agente de Google para Linux estén instalados y ejecutándose. Para obtener más información, consulte Determinación del estado del agente de Google . Si el Agente de Google para Linux no está instalado, vuelva a instalarlo .

  4. Verifique que tenga los roles necesarios para conectarse a la VM. Si su máquina virtual utiliza el inicio de sesión en el sistema operativo, consulte Asignar función de IAM de inicio de sesión en el sistema operativo . Si la máquina virtual no utiliza el inicio de sesión en el sistema operativo, necesita la función de administrador de la instancia informática o la función de usuario de la cuenta de servicio (si la máquina virtual está configurada para ejecutarse como una cuenta de servicio). Los roles son necesarios para actualizar la instancia o los metadatos de claves SSH del proyecto.

  5. Verifique que exista una regla de firewall que permita el acceso SSH ejecutando el siguiente comando:

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

  6. Verifique que exista una ruta predeterminada a Internet (o al host bastión). Para obtener más información, consulte Comprobación de rutas .

  7. Asegúrese de que el volumen raíz no se quede sin espacio en disco. Para obtener más información, consulte Solución de problemas de discos llenos y cambio de tamaño del disco .

  8. Asegúrese de que la VM 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 máquina virtual no tiene memoria, conéctese a la consola serie para solucionar el problema.

Errores de Linux

Permiso denegado (clave pública)

El siguiente error puede ocurrir cuando se conecta a su VM:

USERNAME@VM_EXTERNAL_IP: Permission denied (publickey).

Este error puede ocurrir por varias razones. Las siguientes son algunas de las causas más comunes de este error:

  • Utilizó una clave SSH almacenada en metadatos para conectarse a una máquina virtual que tiene habilitado el inicio de sesión en el sistema operativo. Si el inicio de sesión en el sistema operativo está habilitado en su proyecto, su máquina virtual no acepta claves SSH almacenadas en metadatos. Si no está seguro de si el inicio de sesión en el sistema operativo está habilitado, consulte Comprobar si el inicio de sesión en el sistema operativo está configurado .

    Para resolver este problema, pruebe uno de los siguientes:

  • Usó una clave SSH almacenada en un perfil de inicio de sesión del sistema operativo para conectarse a una máquina virtual que no tiene el inicio de sesión del sistema operativo habilitado. Si desactiva el inicio de sesión del sistema operativo, su máquina virtual no acepta las claves SSH que se almacenaron en su perfil de inicio de sesión del sistema operativo. Si no está seguro de si el inicio de sesión en el sistema operativo está habilitado, consulte Comprobar si el inicio de sesión en el sistema operativo está configurado .

    Para resolver este problema, pruebe uno de los siguientes:

  • La máquina virtual tiene habilitado el inicio de sesión en el sistema operativo, pero no tiene suficientes permisos de IAM para utilizar el inicio de sesión en el sistema operativo. Para conectarse a una máquina virtual que tenga habilitado el inicio de sesión en el sistema operativo, debe tener los permisos necesarios para el inicio de sesión en el sistema operativo. Si no está seguro de si el inicio de sesión en el sistema operativo está habilitado, consulte Comprobar si el inicio de sesión en el sistema operativo está configurado .

    Para resolver este problema, otorgue las funciones de IAM de inicio de sesión del sistema operativo requeridas .

  • Tu clave expiró y Compute Engine eliminó tu archivo ~/.ssh/authorized_keys . Si agregaste manualmente claves SSH a tu VM y luego te conectaste a tu VM usando la consola de Google Cloud, Compute Engine creó un nuevo par de claves para tu conexión. Después de que expiró el nuevo par de claves, Compute Engine eliminó su archivo ~/.ssh/authorized_keys en la VM, que incluía su clave SSH agregada manualmente.

    Para resolver este problema, pruebe uno de los siguientes:

  • Te conectaste usando una herramienta de terceros y tu comando SSH está mal configurado. Si se conecta usando el comando ssh pero no especifica una ruta a su clave privada o especifica una ruta incorrecta a su clave privada, su VM rechaza su conexión.

    Para resolver este problema, pruebe uno de los siguientes:

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

      Reemplace lo siguiente:
      • PATH_TO_PRIVATE_KEY : la ruta a su archivo de clave SSH privada.
      • USERNAME : el nombre de usuario del usuario que se conecta a la instancia. Si administra sus claves SSH en metadatos, el nombre de usuario es el que especificó cuando creó la clave SSH . Para las cuentas de inicio de sesión del sistema operativo , el nombre de usuario se define en su perfil de Google.
      • EXTERNAL_IP : la dirección IP externa de su VM.
    • Conéctese a su máquina virtual mediante la consola de Google Cloud o la CLI de Google Cloud. Cuando usas estas herramientas para conectarte, Compute Engine administra la creación de claves por ti. Para obtener más información, consulte Conexión a máquinas virtuales .

  • El entorno invitado de su VM no se está ejecutando. Si es la primera vez que se conecta a su VM y el entorno invitado no se está ejecutando, entonces la VM podría rechazar su solicitud de conexión SSH.

    Para resolver este problema, haga lo siguiente:

    1. Reinicie la máquina virtual.
    2. En la consola de Google Cloud, inspeccione 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, consulte Validación del entorno de invitado .
    3. Si el entorno invitado no se está ejecutando, instálelo manualmente clonando el disco de inicio de la VM y utilizando un script de inicio .

  • El demonio OpenSSH ( sshd ) no se está ejecutando o no está configurado correctamente. El sshd proporciona acceso remoto seguro al sistema a través del protocolo SSH. Si está mal configurado o no se está ejecutando, no podrá conectarse a su VM a través de SSH.

    Para resolver este problema, pruebe uno o más de los siguientes:

    • Revise la guía del usuario de su sistema operativo para asegurarse de que su sshd_config esté configurado correctamente.

    • Asegúrese de tener la configuración de propiedad y permisos requerida para lo siguiente:

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

      Propiedad

      El entorno invitado almacena 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 invitado requiere los siguientes permisos de Linux:

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

      * Para saber cuál de las opciones es el permiso predeterminado correcto para su directorio $HOME , consulte la documentación oficial de su distribución de Linux específica.

      Alternativamente, puede crear una nueva máquina virtual basada en la misma imagen y verificar sus permisos predeterminados para $HOME .

      Para saber cómo cambiar los permisos y la propiedad, lea sobre chmod y chown .

    • Reinicie el sshd ejecutando el siguiente comando: 

      systemctl restart sshd.service

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

      systemctl status sshd.service

      La salida de estado puede contener información como el código de salida, el motivo del error, etc. Puede utilizar estos detalles para solucionar más problemas.

  • 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, realice 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 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 invitado requiere los siguientes permisos de Linux:

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

    * Para saber cuál de las opciones es el permiso predeterminado correcto para su directorio $HOME , consulte la documentación oficial de su distribución de Linux específica.

    Alternativamente, puede crear una nueva máquina virtual basada en la misma imagen y verificar sus permisos predeterminados para $HOME .

    Para saber cómo cambiar los permisos y la propiedad, lea sobre chmod y chown .

La conexión falló

Los siguientes errores pueden ocurrir cuando te conectas a tu VM desde la consola de Google Cloud, la CLI de gcloud, un host 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 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 ocurrir por varias razones. Las siguientes son algunas de las causas más comunes de los errores:

  • La máquina virtual se está iniciando y sshd aún no se está ejecutando. No puede conectarse a una máquina virtual antes de que se esté ejecutando.

    Para resolver este problema, espere hasta que la VM haya terminado de iniciarse e intente conectarse nuevamente.

  • sshd se ejecuta en un puerto personalizado. Si configuró sshd para ejecutarse en un puerto que no sea el 22, no podrá conectarse a su VM.

    Para resolver este problema, cree una regla de firewall personalizada que permita el tráfico tcp en el puerto en el que se ejecuta su sshd usando 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, consulte Creación de reglas de firewall .

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

    Para resolver este problema, realice una de las siguientes acciones:

    • Si utiliza Identity-Aware Proxy (IAP) para el reenvío de TCP, actualice su regla de firewall personalizada para aceptar el tráfico de IAP y luego verifique sus permisos de IAM.

      1. Actualice su regla de firewall personalizada para permitir el tráfico desde 35.235.240.0/20 , el rango de direcciones IP que IAP utiliza para el reenvío TCP. Para obtener más información, consulte Crear una regla de firewall .
      2. Conceda permisos para utilizar el reenvío TCP IAP , si aún no lo ha hecho.

    • Si no utiliza IAP, actualice su regla de firewall personalizada para permitir el tráfico SSH de ingreso.

      1. Actualice su regla de firewall personalizada para Permitir conexiones ssh de ingreso a máquinas virtuales .

  • La conexión SSH falló después de actualizar el kernel de la VM. Una máquina virtual puede experimentar un pánico en el kernel después de una actualización del kernel, lo que hace que la máquina virtual se vuelva inaccesible.

    Para resolver este problema, haga lo siguiente:

    1. Monte el disco en otra máquina virtual.
    2. Actualice el archivo grub.cfg para usar la versión anterior del kernel.
    3. Conecte el disco a la máquina virtual que no responde.
    4. Verifique que el estado de la máquina virtual sea RUNNING mediante el comando gcloud compute instances describe .
    5. Reinstale el kernel .
    6. Reinicie la máquina virtual.

    Alternativamente, si creó una instantánea del disco de arranque antes de actualizar la VM, use la instantánea para crear una VM .

  • El demonio OpenSSH ( sshd ) no se está ejecutando o no está configurado correctamente. El sshd proporciona acceso remoto seguro al sistema a través del protocolo SSH. Si está mal configurado o no se está ejecutando, no podrá conectarse a su VM a través de SSH.

    Para resolver este problema, pruebe uno o más de los siguientes:

    • Revise la guía del usuario de su sistema operativo para asegurarse de que su sshd_config esté configurado correctamente.

    • Asegúrese de tener la configuración de propiedad y permisos requerida para lo siguiente:

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

      Propiedad

      El entorno invitado almacena 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 invitado requiere los siguientes permisos de Linux:

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

      * Para saber cuál de las opciones es el permiso predeterminado correcto para su directorio $HOME , consulte la documentación oficial de su distribución de Linux específica.

      Alternativamente, puede crear una nueva máquina virtual basada en la misma imagen y verificar sus permisos predeterminados para $HOME .

      Para saber cómo cambiar los permisos y la propiedad, lea sobre chmod y chown .

    • Reinicie el sshd ejecutando el siguiente comando: 

      systemctl restart sshd.service

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

      systemctl status sshd.service

      La salida de estado puede contener información como el código de salida, el motivo del error, etc. Puede utilizar estos detalles para solucionar más problemas.

  • La máquina virtual no arranca y no puede conectarse mediante SSH o la consola serie. Si no se puede acceder a la máquina virtual, es posible que su sistema operativo esté dañado. Si el disco de arranque no arranca, puedes diagnosticar el problema . Si desea recuperar la máquina virtual dañada y recuperar datos, consulte Recuperación de una máquina virtual dañada o un disco de arranque completo .

  • La VM se está iniciando en modo de mantenimiento. Al iniciar en modo de mantenimiento, la VM no acepta conexiones SSH, pero puede conectarse a la consola serie de la VM e iniciar sesión como usuario root.

    Para resolver este problema, haga lo siguiente:

    1. Si no ha establecido una contraseña de root para la VM, use una secuencia de comandos de inicio de metadatos para ejecutar el siguiente comando durante el arranque: 

      echo 'root:NEW_PASSWORD' | chpasswd

      Reemplace NEW_PASSWORD con una contraseña de su elección.

    2. Reinicie la máquina virtual.

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

error inesperado

El siguiente error puede ocurrir cuando intenta conectarse a una máquina virtual 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 ocurrir por varias razones. Las siguientes son algunas causas comunes del error:

  • El demonio OpenSSH ( sshd ) no se está ejecutando o no está configurado correctamente. El sshd proporciona acceso remoto seguro al sistema a través del protocolo SSH. Si está mal configurado o no se está ejecutando, no podrá conectarse a su VM a través de SSH.

    Para resolver este problema, pruebe uno o más de los siguientes:

    • Revise la guía del usuario de su sistema operativo para asegurarse de que su sshd_config esté configurado correctamente.

    • Asegúrese de tener la configuración de propiedad y permisos requerida para lo siguiente:

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

      Propiedad

      El entorno invitado almacena 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 invitado requiere los siguientes permisos de Linux:

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

      * Para saber cuál de las opciones es el permiso predeterminado correcto para su directorio $HOME , consulte la documentación oficial de su distribución de Linux específica.

      Alternativamente, puede crear una nueva máquina virtual basada en la misma imagen y verificar sus permisos predeterminados para $HOME .

      Para saber cómo cambiar los permisos y la propiedad, lea sobre chmod y chown .

    • Reinicie el sshd ejecutando el siguiente comando: 

      systemctl restart sshd.service

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

      systemctl status sshd.service

      La salida de estado puede contener información como el código de salida, el motivo del error, etc. Puede utilizar estos detalles para solucionar más problemas.

  • Problema desconocido del demonio SSH . Para diagnosticar un problema desconocido del demonio SSH, verifique los registros de la consola serie en busca de errores.

    Dependiendo del resultado de los registros de la consola serie, intente rescatar la VM y solucionar los problemas relacionados con el demonio SSH haciendo lo siguiente:

    1. Conecte el disco a otra máquina virtual Linux.
    2. Conéctese a la VM que tiene el disco montado.
    3. Monte el disco dentro del sistema operativo en un directorio MOUNT_DIR dentro de la VM.
    4. Vea los registros relacionados con SSH, /var/log/secure o /var/log/auth.log para detectar cualquier problema o error. Si ve algún problema que pueda solucionar, intente solucionarlo. De lo contrario, cree un caso de soporte y adjunte los registros.

    5. Desmonte el disco del sistema operativo usando el comando umount : 

      cd ~/
umount /mnt

    6. Separe el disco de la VM.

    7. Adjunte el disco a la máquina virtual original.

    8. Inicie la máquina virtual.

No se pudo conectar al backend

Es posible que se produzcan los siguientes errores cuando te conectas a tu VM desde la consola de Google Cloud o la CLI de gcloud:

  • La consola de 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 ocurren cuando intenta usar SSH para conectarse a una máquina virtual que no tiene una dirección IP pública y para la cual no ha configurado Identity-Aware Proxy en el puerto 22.

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

La clave de host no coincide

El siguiente error puede ocurrir cuando se conecta a su VM: 

Host key for server IP_ADDRESS does not match

Este error ocurre cuando la clave de host en el archivo ~/.ssh/known_hosts no coincide con la clave de host de la VM.

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

El valor de los metadatos es demasiado grande.

El siguiente error puede ocurrir cuando intenta agregar una nueva 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, realice una de las siguientes acciones:

errores de windows

Permiso denegado, inténtalo de nuevo.

El siguiente error puede ocurrir cuando se conecta a su 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 CLI de gcloud no está actualizada

    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 resolver este problema, actualiza la CLI de gcloud .

  • Intentó conectarse a una máquina virtual de Windows que no tiene SSH habilitado.

    Para resolver este error, establezca la clave enable-windows-ssh en TRUE en los metadatos del proyecto o de la instancia. Para obtener más información sobre cómo configurar metadatos, consulte Establecer metadatos personalizados .

Permiso denegado (clave pública, teclado interactivo)

El siguiente error puede ocurrir cuando se conecta a una máquina virtual que no tiene SSH habilitado: 

Permission denied (publickey,keyboard-interactive).

Para resolver este error, establezca la clave enable-windows-ssh en TRUE en los metadatos del proyecto o de la instancia. Para obtener más información sobre cómo configurar metadatos, consulte Establecer metadatos personalizados .

No se pudo ingresar mediante SSH a la instancia

Es posible que se produzca el siguiente error cuando te conectas 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 ocurrir por varias razones. Las siguientes son algunas de las causas más comunes de los errores:

Se agotó el tiempo de conexión

Las conexiones SSH agotadas pueden deberse a una de las siguientes causas:

  • La VM no ha terminado de iniciarse. Espere un momento para que se inicie la máquina virtual.

    Para resolver este problema, espere hasta que la VM haya terminado de iniciarse e intente conectarse nuevamente.

  • El paquete SSH no está instalado. Las máquinas virtuales de Windows requieren que instale el paquete google-compute-engine-ssh antes de poder conectarse mediante SSH.

    Para resolver este problema, instale el paquete SSH .

Diagnosticar conexiones SSH fallidas

Las siguientes secciones describen los pasos que puede seguir para diagnosticar la causa de las conexiones SSH fallidas y los pasos que puede seguir para reparar sus conexiones.

Antes de diagnosticar conexiones SSH fallidas, complete los siguientes pasos:

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

Probar conectividad

Es posible que no pueda realizar SSH a una instancia de VM debido a problemas de conectividad vinculados a los firewalls, la conexión de red o la cuenta de usuario. Siga los pasos de esta sección para identificar cualquier problema de conectividad.

Verifique las reglas de su firewall

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

En su estación de trabajo local, ejecute el siguiente comando: 

gcloud compute firewall-rules list

Si falta la regla de firewall, agréguela nuevamente: 

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

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

Pruebe la conexión de red

Para determinar si la conexión de red está funcionando, pruebe el protocolo de enlace TCP:

  1. Obtenga la natIP externa para su VM: 

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

    Reemplace VM_NAME con el nombre de la VM a la que no puede conectarse.

  2. Pruebe la conexión de red a su VM desde su estación de trabajo:

    Linux, Windows 2019/2022 y macOS 

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

    Reemplace lo siguiente:

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

    Si el protocolo de enlace TCP es exitoso, 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 exitoso.

    Ventanas 2012 y 2016 

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

    Reemplace lo siguiente:

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

    Si el protocolo de enlace TCP es exitoso, 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 exitoso.

Si el protocolo de enlace TCP se completa correctamente, una regla de firewall de software no bloquea la conexión, el sistema operativo está reenviando paquetes correctamente y un servidor está escuchando en el puerto de destino. Si el protocolo de enlace TCP se completa correctamente pero la VM no acepta conexiones SSH, el problema podría deberse a que el demonio sshd está mal configurado o no se está ejecutando correctamente. Revise la guía del usuario de su sistema operativo para asegurarse de que su sshd_config esté configurado correctamente.

Para ejecutar pruebas de conectividad para analizar la configuración de la ruta de red de VPC entre dos máquinas virtuales y verificar si la configuración programada debe permitir el tráfico, consulte Verificar reglas de firewall mal configuradas en Google Cloud .

Conéctate como un usuario diferente

El problema que le impide iniciar sesión puede estar limitado a su 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.

Intente iniciar sesión como un usuario diferente con la CLI de gcloud especificando ANOTHER_USERNAME con la solicitud SSH. La CLI de gcloud actualiza los metadatos del proyecto para agregar el nuevo usuario y permitir el acceso SSH. 

gcloud compute ssh ANOTHER_USERNAME@VM_NAME

Reemplace lo siguiente:

  • ANOTHER_USERNAME es un nombre de usuario distinto al suyo
  • VM_NAME es el nombre de la VM a la que desea conectarse

Depurar problemas usando la consola serie

Le recomendamos que revise los registros de la consola serie para detectar errores de conexión. Puede acceder a la consola serie como usuario root desde su estación de trabajo local mediante un navegador. Este enfoque es útil cuando no puede iniciar sesión con SSH o si la instancia no tiene conexión a la red. La consola serie permanece accesible en ambas situaciones.

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

  1. Habilite el acceso interactivo a la consola serie de la VM.

  2. Para máquinas virtuales Linux, modifique la contraseña de root y agregue el siguiente script de inicio a su máquina virtual: 

    echo root:PASSWORD | chpasswd

    Reemplace PASSWORD con una contraseña de su elección.

  3. Utilice la consola serie para conectarse a su VM .

  4. Para las máquinas virtuales Linux, una vez que haya terminado de depurar todos los errores, deshabilite 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

Es posible que tenga una instancia a la que no puede conectarse y que continúa atendiendo correctamente el tráfico de producción. En este caso, es posible que desees inspeccionar el disco sin interrumpir la instancia.

Para inspeccionar y solucionar problemas del disco:

  1. Haga una copia de seguridad de su disco de arranque creando una instantánea del disco .
  2. Cree un disco persistente normal a partir de esa instantánea.
  3. Crea una instancia temporal.
  4. Adjunte y monte el disco persistente normal en su nueva instancia temporal.

Este procedimiento crea una red aislada que solo permite conexiones SSH. Esta configuración evita cualquier consecuencia no deseada de que la instancia clonada interfiera con sus servicios de producción.

  1. Cree una nueva red VPC para alojar su instancia clonada: 

    gcloud compute networks create debug-network

    Reemplace NETWORK_NAME con el nombre con el que desea llamar a su nueva red.

  2. Agregue 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. Cree una instantánea del disco de arranque. 

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

    Reemplace BOOT_DISK_NAME con el nombre del disco de arranque.

  4. Cree un nuevo disco con la instantánea que acaba de crear: 

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

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

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

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

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

  7. Siga las instrucciones para conectarse a una máquina virtual mediante un host bastión .

  8. Una vez que haya iniciado sesión en la instancia del depurador, solucione los problemas de la instancia. Por ejemplo, puede consultar los registros de 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

    Reemplace VM_NAME con el nombre de la VM a la que no puede conectarse.

Utilice un script de inicio

Si nada de lo anterior ayudó, puede crear una secuencia de comandos de inicio para recopilar información inmediatamente después de que se inicie la instancia. Siga las instrucciones para ejecutar un script de inicio .

Luego, también deberás restablecer tu instancia antes de que los metadatos entren en vigencia mediante gcloud compute instances reset .

Alternativamente, también puedes recrear tu instancia ejecutando un script de inicio de diagnóstico:

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

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

    Reemplace VM_NAME con el nombre de la VM a la que no puede conectarse.

  2. Agregue una nueva instancia con el mismo disco y especifique su script de inicio. 

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

    Reemplace lo siguiente:

    • NEW_VM_NAME es el nombre de la nueva VM que estás creando
    • 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 para la secuencia de comandos, ya sea en formato gs:// BUCKET / FILE o https://storage.googleapis.com/ BUCKET / FILE .

Utilice su disco en una nueva instancia

Si aún necesita recuperar datos de su disco de inicio persistente, puede desconectar el disco de inicio y luego conectarlo como disco secundario en una nueva instancia.

  1. Elimine la VM a la que no puede conectarse y conserve su disco de arranque: 

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

    Reemplace VM_NAME con el nombre de la VM a la que no puede conectarse.

  2. Cree una nueva máquina virtual con el disco de arranque de su antigua máquina virtual . Especifique el nombre del disco de arranque de la VM que acaba de eliminar.

  3. Conéctese a su nueva VM usando SSH: 

    gcloud compute ssh NEW_VM_NAME

    Reemplace NEW_VM_NAME con el nombre de su nueva VM.

Compruebe si el disco de arranque de la VM está lleno o no

Es posible que su máquina virtual quede inaccesible si su disco de arranque está lleno. Este escenario puede ser difícil de solucionar ya que no siempre es obvio cuando el problema de conectividad de la VM se debe a un disco de arranque lleno. Para obtener más información sobre este escenario, consulte Solución de problemas de una máquina virtual a la que no se puede acceder debido a un disco de arranque lleno .

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

Restablecer metadatos SSH

Si no puede conectarse a una máquina virtual Windows mediante SSH, intente desarmar la clave de metadatos enable-windows-ssh y volver a habilitar SSH para Windows.

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

    Espere unos segundos a que se produzca el cambio.

  2. Vuelva a habilitar SSH para Windows

  3. Vuelva a conectarse a la máquina virtual .

Conéctese a la VM usando RDP

Si no puede diagnosticar y resolver la causa de las conexiones SSH fallidas a su máquina virtual Windows, conéctese mediante RDP .

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

¿Qué sigue?