Fehler beim Zugriff beheben

Auf dieser Seite finden Sie Tipps zur Fehlerbehebung bei Zugriffsproblemen bei Bare-Metal-Lösung.

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

SSH-Client kann keine Verbindung herstellen

Wenn Ihr SSH-Client keine Verbindung zu einem Server herstellen kann, wird möglicherweise einer der folgenden Fehler angezeigt:

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 mit den Befehlen ping, traceroute und nc, ob der Host erreichbar ist und der SSH-Port (22) offen ist.
```
ping SERVER_NAME
```
```
traceroute SERVER_NAME
```
```
echo "" | nc SERVER_NAME 22
```
Wenn dies nicht funktioniert, liegt das Problem möglicherweise auf der Netzwerkebene und nicht auf der SSH-Verbindung.
Sehen Sie sich die clientseitige Debug-Ausgabe an.
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 Schlüsselereignisse des clientseitigen SSH-Protokolls enthält.
  
  Die folgende Beispielausgabe zeigt, dass der Client seinen Schlüssel gesendet, aber vom Server abgelehnt wurde. Der Server hat die Authentifizierung mit einem anderen öffentlichen Schlüssel fortgesetzt, der Client hat jedoch keine zusätzlichen Schlüssel zur Verfügung gestellt.
```
.. .. ..
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 eindeutig angibt, führen Sie den Befehl strace aus:
```
strace ssh SERVER_NAME -i ~/.ssh/id_ecdsa > strace-ssh.txt 2>&1
```
3. Prüfen Sie die Ausgabe von strace auf Fehler im Zusammenhang mit dem Kernproblem.
  
  In manchen Fällen reicht die clientseitige Debug-Ausgabe nicht aus, um das Problem zu identifizieren. Möglicherweise müssen Sie auch serverseitiges Tracing ausführen, um den Fehler zu finden. Bis Sie eine SSH-Verbindung zu Ihrem Server herstellen können, verwenden Sie die interaktive serielle Konsole, um die nächsten Schritte auszuführen.
Sehen Sie sich die serverseitige Debug-Ausgabe an.
1. Suchen Sie die aktuellen SSH-Einstellungen.
```
grep -v "^#" /etc/ssh/sshd_config | grep -v "^$"
```
2. Um detaillierte Informationen zu SSH zu erhalten, legen Sie die folgenden Parameter in der Datei /etc/ssh/sshd_config fest.
```
SyslogFacility AUTH
LogLevel DEBUG
```
3. Starten Sie den Dienst neu, um die Änderungen zu übernehmen.
```
service sshd restart
```
4. Führen Sie auf der Clientseite den Befehl ssh aus und extrahieren Sie die sshd-Meldungen aus den Logs:
```
grep sshd /var/log/messages
```
  Alternativ können Sie alle relevanten Nachrichten für den Zeitraum mit dem folgenden Befehl exportieren:
```
journalctl -u sshd -S "START_TIME" -U "END_TIME" --utc
```
  Ersetzen Sie Folgendes:
  - START_TIME: Die Startzeit 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 Client-Schlüsseldatei schreibgeschützt ist (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üfen Sie auf Serverseite, ob der öffentliche Clientschlüssel in der lokalen Konfigurationsdatei des entsprechenden Nutzers angegeben ist (~/.ssh/authorized_keys).
In einigen Fällen kann das Problem mit der SSH-Protokollversion oder dem SSH-Algorithmus zusammenhängen. Die server- und die clientseitigen Debug-Ausgaben können auf ein solches Problem hindeuten. In der Regel finden Sie auf den man-Seiten für ssh und sshd_config Details zum Verwalten der erforderlichen Konfiguration. Mit den folgenden Befehlen können Sie beispielsweise die unterstützten Algorithmen oder Chiffren für den Schlüsselaustausch finden:
```
# Find key exchange algorithms
ssh -Q kex
# Find the symmetric encryption ciphers
ssh -Q cipher
```