Fehlerbehebung für Bare-Metal-Lösung

Diese Seite enthält Tipps zur Fehlerbehebung bei Problemen mit der Bare-Metal-Lösung.

Prüfen Sie, ob Ihre Frage oder Ihr Problem bereits auf der Seite Bekannte Probleme und Einschränkungen behandelt wurde.

Zugriffsprobleme

In diesem Abschnitt finden Sie Zugriffsprobleme, die auftreten können, sowie Vorschläge zur Behebung.

SSH-Client kann keine Verbindung herstellen

Wenn Ihr SSH-Client keine Verbindung zu einem Server herstellen kann, sehen Sie möglicherweise einen der folgenden Fehler:

connection timeout oder connection refused: Der SSH-Client kann keine Verbindung herstellen.
Permission denied (publickey): Der SSH-Client kann nicht authentifiziert werden.

So diagnostizieren Sie fehlgeschlagene SSH-Verbindungen:

Verbindung testen

Prüfen Sie, ob der Host erreichbar ist und ob der SSH-Port (22) mit den Befehlen ping, traceroute und nc geöffnet ist.
```
ping SERVER_NAME
```
```
traceroute SERVER_NAME
```
```
echo "" | nc SERVER_NAME 22
```
Wenn dies nicht funktioniert, liegt das Problem möglicherweise an der Netzwerkebene und nicht an der SSH-Verbindung.
Prüfen Sie die clientseitige Fehlerbehebungsausgabe.
1. Aktivieren Sie die Ausführlichkeit des SSH-Protokolls.
```
ssh -v SERVER_NAME -i ~/.ssh/id_ecdsa
```
  Der Befehl gibt die Debug-Ausgabe aus, die die wichtigsten Ereignisse des clientseitigen SSH-Protokolls zeigt.
  
  Die folgende Beispielausgabe zeigt, dass der Client seinen Schlüssel gesendet hat, der Server ihn jedoch abgelehnt hat. Der Server hat die Authentifizierung aufgefordert, mit einem anderen öffentlichen Schlüssel fortzufahren, aber der Client hat keine zusätzlichen Schlüssel zum Angebot.
```
.. .. ..
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. Wenn die ausführliche SSH-Ausgabe die Ursache der Fehlermeldung nicht klar angibt, führen Sie den Befehl strace aus:
```
strace ssh SERVER_NAME -i ~/.ssh/id_ecdsa > strace-ssh.txt 2>&1
```
3. Überprüfen Sie die strace-Ausgabe auf Fehler im Zusammenhang mit dem Kernproblem.
  
  In einigen Fällen reicht die clientseitige Fehlerbehebungsausgabe nicht aus, um das Problem zu identifizieren. Möglicherweise müssen Sie auch serverseitiges Tracing ausführen, um den Fehler zu finden. Verwenden Sie die interaktiven seriellen Konsole, um die nächsten Schritte auszuführen, bis Sie keine SSH-Verbindung zu Ihrem Server herstellen können.
Untersuchen Sie die Ausgabe des serverseitigen Debuggings.
1. Rufen Sie die aktuellen SSH-Einstellungen auf.
```
grep -v "^#" /etc/ssh/sshd_config | grep -v "^$"
```
2. Wenn Sie detaillierte Informationen zu SSH erhalten möchten, legen Sie in der Datei /etc/ssh/sshd_config die folgenden Parameter fest.
```
SyslogFacility AUTH
LogLevel DEBUG
```
3. Starten Sie den Dienst neu, um die Änderungen zu übernehmen.
```
service sshd restart
```
4. Führen Sie auf Clientseite den Befehl ssh aus und extrahieren Sie die sshd-Nachrichten aus den Logs:
```
grep sshd /var/log/messages
```
  Alternativ können Sie mit dem folgenden Befehl alle relevanten Nachrichten für den Zeitraum exportieren:
```
journalctl -u sshd -S "START_TIME" -U "END_TIME" --utc
```
  Dabei gilt:
  - START_TIME: Der Beginn des Zeitraums im Format yyyy-mm-dd hh:mm:ss.
  - END_TIME: Das Ende des Zeitraums im Format yyyy-mm-dd hh:mm:ss.
  Beispiel:
```
journalctl -u sshd -S "2023-04-25 18:38:00" -U "2023-04-25 18:40:00" --utc
```

So beheben Sie diese Probleme:

Prüfen Sie, ob die Clientschlüsseldatei schreibgeschützte Berechtigungen hat (Flag 400). Andernfalls akzeptiert der SSH-Client sie nicht.

Führen Sie den folgenden Befehl aus, um das schreibgeschützte Flag für den verwendeten privaten Schlüssel festzulegen:
```
chmod 400 ~/.ssh/id_ed25519
```
Prüfe auf Serverseite, ob der öffentliche Clientschlüssel in der lokalen Konfigurationsdatei des entsprechenden Nutzers (~/.ssh/authorized_keys) angegeben ist.
In einigen Fällen hängt das Problem mit der Version des SSH-Protokolls oder dem SSH-Algorithmus zusammen. Die serverseitigen und clientseitigen Debug-Ausgaben können auf ein solches Problem hinweisen. In der Regel finden Sie auf den man-Seiten für ssh und sshd_config Informationen zum Beibehalten der erforderlichen Konfiguration. Suchen Sie beispielsweise mit den folgenden Befehlen nach den unterstützten Schlüsselaustauschalgorithmen oder Chiffren, die unterstützt werden:
```
# Find key exchange algorithms
ssh -Q kex
# Find the symmetric encryption ciphers
ssh -Q cipher
```