Diese Seite wurde von der Cloud Translation API übersetzt.

Fehler beim Zugriff beheben

Auf dieser Seite finden Sie Tipps zur Fehlerbehebung bei Problemen mit dem Zugriff auf die Bare-Metal-Lösung.

Überprüfen Sie, ob Ihre Frage oder Ihr Problem bereits im Seite Bekannte Probleme und Einschränkungen

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 sich nicht authentifizieren.

So diagnostizieren Sie fehlgeschlagene SSH-Verbindungen:

Teste die Verbindung.

Achten Sie darauf, dass der Host erreichbar und der SSH-Port (22) geöffnet ist mit den Befehlen ping, traceroute und nc.
```
ping SERVER_NAME
```
```
traceroute SERVER_NAME
```
```
echo "" | nc SERVER_NAME 22
```
Wenn dies nicht funktioniert, liegt das Problem möglicherweise in der Netzwerkschicht und nicht mit SSH.
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, in der die Schlüsselereignisse der clientseitiges SSH-Protokoll.
  
  Die folgende Beispielausgabe zeigt, dass der Client seinen Schlüssel gesendet, aber der Server ihn abgelehnt hat. Der Server hat den -Authentifizierung, um mit einem anderen öffentlichen Schlüssel fortzufahren, aber der Client hat keinen zusätzliche Schlüssel, die Sie anbieten können.
```
.. .. ..
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 nicht eindeutig die Ursache der Fehlermeldung 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 strace-Ausgabe auf Fehler im Zusammenhang mit dem Hauptproblem.
  
  In einigen 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 die Fehler. Bis Sie keine SSH-Verbindung zu Ihrem Server herstellen können, verwenden Sie die Methode interaktive serielle Konsole um die nächsten Schritte durchzuführen.
Prüfen Sie die serverseitige Debugausgabe.
1. Suchen Sie die aktuellen SSH-Einstellungen.
```
grep -v "^#" /etc/ssh/sshd_config | grep -v "^$"
```
2. Wenn Sie detaillierte Informationen zu SSH erhalten möchten, legen Sie die folgenden Parameter in der /etc/ssh/sshd_config-Datei fest.
```
SyslogFacility AUTH
LogLevel DEBUG
```
3. Starten Sie den Dienst neu, um die Änderungen anzuwenden.
```
service sshd restart
```
4. Führen Sie clientseitig den Befehl ssh aus und extrahieren Sie den sshd Nachrichten aus den Protokollen:
```
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: Die Endzeit 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 können Sie diese Probleme beheben:

Prüfen Sie, ob die Clientschlüsseldatei schreibgeschützte Berechtigungen hat (Flag 400). Andernfalls akzeptiert der SSH-Client ihn 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 der Serverseite, ob der öffentliche Clientschlüssel in der lokalen Konfigurationsdatei (~/.ssh/authorized_keys) des entsprechenden Nutzers angegeben ist.
In einigen Fällen kann das Problem mit der SSH-Protokollversion oder dem SSH-Algorithmus zusammenhängen. Die server- und clientseitigen Debug-Ausgaben können auf ein solches Problem hinweisen. Normalerweise finden Sie auf den man-Seiten für ssh und sshd_config die Details zur Aufrechterhaltung der erforderlichen Konfiguration. Wenn Sie beispielsweise die unterstützten Schlüsselaustauschalgorithmen oder -verschlüsselungen ermitteln möchten, verwenden Sie die folgenden Befehle:
```
# Find key exchange algorithms
ssh -Q kex
# Find the symmetric encryption ciphers
ssh -Q cipher
```