Cette page a été traduite par l'API Cloud Translation.

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 a déjà été résolu sur la page Problèmes connus et limites.

Client SSH ne parvenant 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 parvient pas à se connecter.
Permission denied (publickey): l'authentification du client SSH échoue.

Pour diagnostiquer les échecs de 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 être lié à la couche réseau et non au SSH.
Examinez la sortie de débogage côté client.
1. Activez la verbosité du protocole SSH.
```
ssh -v SERVER_NAME -i ~/.ssh/id_ecdsa
```
  La commande affiche la sortie 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 rejetée. Le serveur a demandé à l'authentification de continuer avec une autre clé publique, mais le client ne dispose d'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 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. Examinez la sortie strace pour détecter les erreurs liées au problème principal.
  
  Dans certains cas, la sortie de débogage côté client n'est pas suffisante pour identifier le problème. Vous devrez peut-être également exécuter le traçage côté serveur pour trouver l'erreur. Tant que vous ne pouvez pas vous connecter à votre serveur via SSH, 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 le protocole 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 pour 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 pour maintenir la configuration requise. Par exemple, pour trouver 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
```