Soluciona problemas de SSH

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

Errores de SSH comunes

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

Permiso denegado

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.

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

  • Usaste una Llave 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 Llaves SSH que se almacenaron en tu perfil del acceso al SO.

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

  • 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 Google Cloud Console, 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:

    • Conéctate a la VM mediante Google Cloud Console o la herramienta de línea de comandos de gcloud. Para obtener más información, consulta Conéctate a VM.
    • Vuelve a agregar tu clave SSH a los metadatos. Para obtener más información, consulta Edita metadatos de claves SSH públicas.
  • 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:
    • Conéctate a la VM mediante Google Cloud Console o la herramienta de línea de comandos de gcloud. 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 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 Cloud Console, 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 sshd no está en ejecución o no está configurado de forma correcta. El daemon sshd habilita las conexiones SSH. Si está mal configurada o no está en ejecución, no puedes conectarte a la VM.

    Para solucionar este problema, revisa la guía del usuario de tu sistema operativo a fin de asegurarte de que tu sshd_config esté configurado correctamente.

No se pudo establecer la conexión

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

  • Cloud Console:

     
    Connection Failed

    We are unable to connect to the VM on port 22.
  • La herramienta gcloud, puede realizar lo siguiente:

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

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.

  • Falta la regla de firewall que permite la conexión SSH o está mal configurada. De forma predeterminada, las VM de Compute Engine permiten el acceso SSH en el puerto 22. Si la regla default-allow-ssh falta o está mal configurada, no podrás conectarte a las VM.

    Para resolver este problema, verifica tus reglas de firewall y vuelve a agregar o configurar default-allow-ssh.

  • 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.

  • Tu regla de firewall SSH personalizada no permite el tráfico de los servicios de Google. Las conexiones SSH desde Cloud Console se rechazan si las reglas de firewall personalizadas no permiten conexiones desde el rango de direcciones IP de Google.

    Para solucionar este problema, haz lo siguiente:

    1. Recopila los rangos de direcciones IP de Google mediante la ejecución del siguiente comando:

       
      dig +qr +short txt `dig +short TXT _spf.google.com | grep -oE 'include:\S*' | cut -d':' -f2 | xargs` | grep -oE 'ip[46]:\S*' | sort | uniq
    2. Actualiza tu regla de firewall personalizada para permitir el tráfico desde las direcciones IP de Google. Para obtener más información, consulta Actualiza las reglas de firewall.

  • 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 sshd no está en ejecución o no está configurado de forma correcta. El daemon sshd habilita las conexiones SSH. Si está mal configurada o no está en ejecución, no puedes conectarte a la VM.

    Para solucionar este problema, revisa la guía del usuario de tu sistema operativo a fin de asegurarte de que tu sshd_config esté configurado correctamente.

  • 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 "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.

No se pudo establecer una conexión con el backend

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

  • Cloud Console:

     
    -- Connection via Cloud Identity-Aware Proxy Failed

    -- Code: 4003

    -- Reason: failed to connect to backend
  • La herramienta gcloud, puede realizar lo siguiente:

     
    ERROR: (gcloud.compute.start-iap-tunnel) Error while connecting [4003: u'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.

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:

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

A fin de determinar si la conexión de red funciona, usa la herramienta nmap para conectarte a la instancia en el puerto 22. Si cuando te conectas ves 22/tcp open ssh, significa que la conexión de red funciona y puedes descartar problemas de firewall.

  1. Usa la herramienta gcloud si quieres obtener la natIP externa para tu instancia:

     
    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 instancia.

    Ejecuta el comando nmap para probar la conexión de red a la instancia y reemplaza external-ip por la IP externa que obtuviste en el paso 1:

     
    nmap external-ip

    Por ejemplo, si la instancia tiene la IP externa 198.51.100.1, ejecuta el siguiente comando:

     
    nmap 198.51.100.1
     
    Starting Nmap 7.70 ( https://nmap.org ) at 2019-03-18 16:04 Greenwich Standard Time
    Nmap scan report for 229.30.196.35.bc.googleusercontent.com (198.51.100.1)
    Host is up (0.0061s latency).
    Not shown: 998 filtered ports
    PORT STATE SERVICE
    22/tcp open ssh
    Nmap done: 1 IP address (1 host up) scanned in 6.22 seconds

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 herramienta de gcloud. Para ello, especifica ANOTHER_USERNAME con la solicitud SSH. La herramienta de gcloud 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 el problema en la consola en serie

Te recomendamos que revises los registros de la consola en serie para detectar errores de conexión. Puedes acceder a la consola en serie desde tu estación de trabajo local con un navegador.

Habilita el acceso de lectura/escritura a la consola en serie de una instancia para poder acceder a la consola y solucionar problemas con la instancia. 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 saber cómo habilitar el acceso interactivo y conectarte a la consola en serie de una instancia, consulta Interactúa con la consola en serie.

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. Siga las instrucciones para conectarte a una instancia sin una dirección IP externa.

  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:

     
    gcloud compute instances create NEW_VM_NAME \
    --disk name=BOOT_DISK_NAME,boot=yes,auto-delete=no

    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.
  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.