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 ya se abordó tu pregunta o problema en la página Problemas conocidos y limitaciones.

No se puede conectar el cliente SSH

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

connection timeout o connection refused: El cliente SSH no se puede conectar.
Permission denied (publickey): El cliente SSH no se puede autenticar.

Para diagnosticar conexiones SSH fallidas, sigue estos pasos:

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.
Examina el resultado de depuración del lado 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 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 solicitó 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 con claridad 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 la depuración del lado 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 no puedas establecer una conexión SSH a tu servidor, usa la consola en serie interactiva para realizar los siguientes pasos.
Examina el resultado de 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, configura 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
```
  O bien, puedes exportar todos los mensajes relevantes para el período mediante 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 claves del cliente está configurado con permisos de solo lectura (marca 400). De lo contrario, el cliente SSH no lo acepta.

Para configurar la marca de solo lectura de 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 con el algoritmo SSH. Los resultados de depuración del lado del servidor y del cliente pueden indicar este problema. Por lo general, las páginas de man de ssh y sshd_config proporcionan los detalles para mantener la configuración necesaria. Por ejemplo, para encontrar los algoritmos de cifrado o los algoritmos de intercambio de claves compatibles, usa los siguientes comandos:
```
# Find key exchange algorithms
ssh -Q kex
# Find the symmetric encryption ciphers
ssh -Q cipher
```