Cómo solucionar problemas de acceso

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

Verifica si tu pregunta o problema ya se resolvió en el Página de problemas conocidos y limitaciones

El cliente SSH no puede conectarse

Si tu cliente SSH no se conecta 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 puede autenticar.

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 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 clave de la protocolo SSH del lado del cliente.

      El siguiente resultado de ejemplo muestra que el 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 el 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 problema. Quizás también debas ejecutar el seguimiento del servidor para encontrar . Hasta que no puedas establecer una conexión SSH a tu servidor, usa el 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 el sshd mensajes 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: La hora de inicio del período en el formato yyyy-mm-dd hh:mm:ss.
      • END_TIME: 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 claves de cliente está configurado con permisos de solo lectura (marca 400). De lo contrario, el cliente SSH no lo acepta.

    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, comprueba 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. Las salidas de depuración del lado del servidor y del cliente podrían indican dicho problema. 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