Soluciona problemas de SSH

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

Errores comunes de SSH

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 puede ocurrir cuando te conectas a tu VM:

USERNAME@VM_EXTERNAL_IP: Permission denied (publickey).

Este error puede deberse a 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, pruebe una de las siguientes opciones:

  • 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, pruebe una de las siguientes opciones:

  • Tu clave caducó y Compute Engine borró tu archivo ~/.ssh/authorized_keys. Si agregaste Llaves SSH de forma manual a tu VM y, luego, te conectaste a tu VM mediante Google Cloud Console, Compute Engine creó un nuevo par de claves para tu conexión. Después del vencimiento del par de claves nuevo, Compute Engine borró tu archivo ~/.ssh/authorized_keys en la VM, que incluye tu Llave SSH agregada de forma manual.

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

    • Conéctate a tu 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 Llave SSH a los metadatos. Para obtener más información, consulta Edita metadatos de Llaves 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 especificas una ruta de acceso incorrecta a tu clave privada, la VM rechazará tu conexión.

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

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

      Reemplaza lo siguiente:
    • Conéctate a tu 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 daemon sshd no se está ejecutando o no está configurado correctamente. El daemon sshd habilita las conexiones SSH. Si está mal configurada o no se está ejecutando, no puedes conectarte a tu 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 producirse por varios motivos. Las siguientes son algunas de las causas más comunes de los errores:

  • La VM se está iniciando y sshd aún no está en ejecución. No puedes conectarte a una VM antes de que se ejecute.

    Para resolver este problema, espera hasta que la VM termine de iniciarse y vuelve a intentar conectarte.

  • Falta la configuración de 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 las reglas de tu firewall y vuelve a agregar o volver a configurar default-allow-ssh.

  • sshd se está ejecutando en un puerto personalizado. Si configuraste sshd para que se ejecute en un puerto que no sea el puerto 22, no podrás conectarte a tu 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 tu sshd con 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 de 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. Para recopilar los rangos de direcciones IP de Google, ejecute el 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.

  • El daemon sshd no se está ejecutando o no está configurado correctamente. El daemon sshd habilita las conexiones SSH. Si está mal configurada o no se está ejecutando, no puedes conectarte a tu 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 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.

Diagnóstico de conexiones SSH fallidas

En las siguientes secciones, se describen los pasos que puedes seguir para diagnosticar la causa de las conexiones SSH fallidas y los pasos que puedes seguir para corregir tus conexiones.

Antes de diagnosticar las conexiones SSH fallidas, 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 tu 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 VM nueva 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.

Como punto de partida, puedes usar la secuencia de comandos compute-ssh-diagnostic para recopilar información de diagnóstico de los problemas más comunes.

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 conserva 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 tu 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 VM nueva 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 VM nueva.

¿Qué sigue?