Cómo solucionar problemas de acceso

En esta página, se proporcionan sugerencias para solucionar problemas de acceso a la solución Bare Metal.

Comprueba si tu pregunta o problema ya se abordó en la página Problemas y limitaciones conocidos.

El cliente SSH no puede conectarse

Si tu cliente de SSH no se puede conectar a un servidor, es posible que veas uno de los siguientes errores:

  • connection timeout o connection refused: El cliente SSH no puede conectarse.

  • Permission denied (publickey): El cliente SSH no se autentica.

Para diagnosticar las conexiones SSH con errores, sigue estos pasos:

  1. Prueba la conectividad.

    Asegúrate de que se pueda acceder al host y de que el puerto SSH (22) esté abierto con los comandos ping, traceroute y nc.

    ping SERVER_NAME
    
    traceroute SERVER_NAME
    
    echo "" | nc SERVER_NAME 22
    

    Si esto no funciona, es posible que el problema esté en la capa de red y no en el SSH.

  2. Examina el resultado de la depuración del cliente.

    1. Activa la verbosidad del protocolo SSH.

      ssh -v SERVER_NAME -i ~/.ssh/id_ecdsa
      

      El comando imprime el resultado de depuración que muestra los eventos de teclas del protocolo SSH del cliente.

      En el siguiente resultado de ejemplo, se muestra que el cliente envió su clave, pero el servidor la rechazó. El servidor le pidió a la autenticación que continuara con otra clave pública, pero el cliente no tiene claves adicionales para ofrecer.

      .. .. ..
      debug1: Server host key: ecdsa-sha2-nistp256 SHA256:V9cRYdqcAJv+RPfN+oofNTVdUxs6VlocP4uMWOxeGKI
      debug1: Host 'bms-server' is known and matches the ECDSA host key.
      debug1: Found key in /root/.ssh/known_hosts:1
      debug1: rekey after 134217728 blocks
      debug1: SSH2_MSG_NEWKEYS sent
      debug1: expecting SSH2_MSG_NEWKEYS
      debug1: SSH2_MSG_NEWKEYS received
      debug1: rekey after 134217728 blocks
      debug1: SSH2_MSG_EXT_INFO received
      debug1: kex_input_ext_info: server-sig-algs=
      debug1: SSH2_MSG_SERVICE_ACCEPT received
      debug1: Authentications that can continue: publickey
      debug1: Next authentication method: publickey
      debug1: Offering ECDSA public key: /root/.ssh/id_ecdsa
      debug1: Authentications that can continue: publickey
      debug1: No more authentication methods to try.
      Permission denied (publickey).
      
    2. Si el resultado detallado de SSH no indica claramente la causa del mensaje de error, ejecuta el comando strace:

      strace ssh SERVER_NAME -i ~/.ssh/id_ecdsa > strace-ssh.txt 2>&1
      
    3. Examina el resultado de strace en busca de errores relacionados con el problema principal.

      En algunos casos, el resultado de depuración del cliente no es suficiente para identificar el problema. Es posible que también debas ejecutar el seguimiento del servidor para encontrar el error. Hasta que puedas conectarte a tu servidor a través de SSH, usa la consola en serie interactiva para realizar los siguientes pasos.

  3. Examina el resultado de la depuración del servidor.

    1. Busca la configuración actual de SSH.

      grep -v "^#" /etc/ssh/sshd_config | grep -v "^$"
      
    2. Para obtener información detallada sobre SSH, establece los siguientes parámetros en el archivo /etc/ssh/sshd_config.

      SyslogFacility AUTH
      LogLevel DEBUG
      
    3. Para aplicar los cambios, reinicia el servicio.

      service sshd restart
      
    4. En el lado del cliente, ejecuta el comando ssh y extrae los mensajes sshd de los registros:

      grep sshd /var/log/messages
      

      También puedes exportar todos los mensajes relevantes del período con el siguiente comando:

      journalctl -u sshd -S "START_TIME" -U "END_TIME" --utc
      

      Reemplaza lo siguiente:

      • START_TIME: Es la hora de inicio del período en formato yyyy-mm-dd hh:mm:ss.
      • END_TIME: Es la hora de finalización del período en formato yyyy-mm-dd hh:mm:ss.

      Ejemplo:

      journalctl -u sshd -S "2023-04-25 18:38:00" -U "2023-04-25 18:40:00" --utc
      

Para solucionar estos problemas, considera los siguientes pasos:

  • Verifica si el archivo de clave del cliente está configurado con permisos de solo lectura (marca 400). De lo contrario, el cliente SSH no lo aceptará.

    Para establecer la marca de solo lectura para la clave privada que está en uso, ejecuta el siguiente comando:

    chmod 400 ~/.ssh/id_ed25519
    
  • En el servidor, verifica si la clave pública del cliente se especifica en el archivo de configuración local del usuario correspondiente (~/.ssh/authorized_keys).

  • En algunos casos, el problema puede estar relacionado con la versión del protocolo SSH o el algoritmo SSH. Los resultados de depuración del servidor y del cliente pueden indicar un problema de este tipo. Por lo general, las páginas man de ssh y sshd_config proporcionan los detalles para mantener la configuración necesaria. Por ejemplo, para encontrar los algoritmos de intercambio de claves o los algoritmos de cifrado compatibles, usa los siguientes comandos:

    # Find key exchange algorithms
    ssh -Q kex
    # Find the symmetric encryption ciphers
    ssh -Q cipher