Résoudre les problèmes d'accès

Cette page fournit des conseils de dépannage pour les problèmes d'accès à la solution Bare Metal.

Vérifiez si votre question ou votre problème ont déjà été traités sur la page Limites et problèmes connus.

Le client SSH ne parvient pas à se connecter

Si votre client SSH ne parvient pas à se connecter à un serveur, l'une des erreurs suivantes peut s'afficher:

connection timeout ou connection refused: le client SSH ne peut pas se connecter.
Permission denied (publickey): le client SSH ne parvient pas à s'authentifier.

Pour diagnostiquer l'échec des connexions SSH, procédez comme suit:

Testez la connectivité.

Assurez-vous que l'hôte est accessible et que le port SSH (22) est ouvert à l'aide des commandes ping, traceroute et nc.
```
ping SERVER_NAME
```
```
traceroute SERVER_NAME
```
```
echo "" | nc SERVER_NAME 22
```
Si cela ne fonctionne pas, le problème peut provenir de la couche réseau et non de SSH.
Examinez la sortie de débogage côté client.
1. Activez le niveau de verbosité du protocole SSH.
```
ssh -v SERVER_NAME -i ~/.ssh/id_ecdsa
```
  La commande imprime la sortie de débogage qui affiche les événements de touche du protocole SSH côté client.
  
  L'exemple de résultat suivant montre que le client a envoyé sa clé, mais que le serveur l'a refusée. Le serveur a demandé à l'authentification de continuer avec une autre clé publique, mais le client n'a aucune clé supplémentaire à proposer.
```
.. .. ..
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 la sortie SSH détaillée n'indique pas clairement la cause du message d'erreur, exécutez la commande strace:
```
strace ssh SERVER_NAME -i ~/.ssh/id_ecdsa > strace-ssh.txt 2>&1
```
3. Examinez la sortie strace pour identifier les erreurs liées au problème principal.
  
  Dans certains cas, les résultats de débogage côté client ne suffisent pas à identifier le problème. Vous devrez peut-être également exécuter un traçage côté serveur pour identifier l'erreur. Tant que vous ne pouvez pas vous connecter en SSH à votre serveur, utilisez la console série interactive pour effectuer les étapes suivantes.
Examinez la sortie de débogage côté serveur.
1. Recherchez les paramètres SSH actuels.
```
grep -v "^#" /etc/ssh/sshd_config | grep -v "^$"
```
2. Pour obtenir des informations détaillées sur SSH, définissez les paramètres suivants dans le fichier /etc/ssh/sshd_config.
```
SyslogFacility AUTH
LogLevel DEBUG
```
3. Pour appliquer les modifications, redémarrez le service.
```
service sshd restart
```
4. Côté client, exécutez la commande ssh et extrayez les messages sshd des journaux:
```
grep sshd /var/log/messages
```
  Vous pouvez également exporter tous les messages pertinents pour la période donnée à l'aide de la commande suivante:
```
journalctl -u sshd -S "START_TIME" -U "END_TIME" --utc
```
  Remplacez les éléments suivants :
  - START_TIME: heure de début de la période au format yyyy-mm-dd hh:mm:ss.
  - END_TIME: heure de fin de la période au format yyyy-mm-dd hh:mm:ss.
  Exemple :
```
journalctl -u sshd -S "2023-04-25 18:38:00" -U "2023-04-25 18:40:00" --utc
```

Pour résoudre ces problèmes, procédez comme suit:

Vérifiez si le fichier de clé client est défini avec des autorisations en lecture seule (indicateur 400). Sinon, le client SSH ne l'accepte pas.

Pour définir l'indicateur de lecture seule de la clé privée utilisée, exécutez la commande suivante:
```
chmod 400 ~/.ssh/id_ed25519
```
Côté serveur, vérifiez si la clé publique du client est spécifiée dans le fichier de configuration local de l'utilisateur correspondant (~/.ssh/authorized_keys).
Dans certains cas, le problème peut être lié à la version du protocole SSH ou à l'algorithme SSH. Les résultats de débogage côté serveur et côté client peuvent indiquer un tel problème. En règle générale, les pages man pour ssh et sshd_config fournissent les détails nécessaires pour maintenir la configuration nécessaire. Par exemple, pour rechercher les algorithmes d'échange de clés ou les algorithmes de chiffrement compatibles, utilisez les commandes suivantes:
```
# Find key exchange algorithms
ssh -Q kex
# Find the symmetric encryption ciphers
ssh -Q cipher
```