Résoudre les problèmes liés à la solution Bare Metal

Cette page fournit des conseils pour résoudre les problèmes liés à la solution Bare Metal.

Vérifiez si votre question ou problème a déjà été résolu sur la page Problèmes connus et limites.

Problèmes d'accès

Cette section répertorie les problèmes d'accès que vous pouvez rencontrer et fournit des suggestions sur la façon de les résoudre.

Connexion du client SSH impossible

Si votre client SSH ne parvient pas à se connecter à un serveur, vous pouvez rencontrer l'une des erreurs suivantes:

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 les échecs de connexion 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 du SSH.
Examinez la sortie du débogage côté client.
1. Activez la verbosité du protocole SSH.
```
ssh -v SERVER_NAME -i ~/.ssh/id_ecdsa
```
  La commande affiche le résultat de débogage qui affiche les événements clés 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 plus de clés supplémentaires à 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 détaillée SSH 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. Recherchez dans la sortie strace les erreurs liées au problème principal.
  
  Dans certains cas, les résultats du débogage côté client ne suffisent pas à identifier le problème. Vous devrez peut-être également exécuter le traçage côté serveur pour identifier l'erreur. Avant de pouvoir vous connecter en SSH à votre serveur, effectuez les étapes suivantes à l'aide de la console série interactive.
Examinez la sortie du 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 à 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 en 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 sorties 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 à la gestion de la configuration nécessaire. Par exemple, pour rechercher les algorithmes d'échange de clés ou les algorithmes de chiffrement compatibles, exécutez les commandes suivantes:
```
# Find key exchange algorithms
ssh -Q kex
# Find the symmetric encryption ciphers
ssh -Q cipher
```