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.

Prüfen Sie, ob Ihre Frage oder das Problem bereits auf der Seite Bekannte Probleme und Einschränkungen beantwortet 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 sich nicht authentifizieren.

So diagnostizieren Sie fehlgeschlagene SSH-Verbindungen:

Testen Sie die Verbindung.

Prüfen Sie mit den Befehlen ping, traceroute und nc, ob der Host erreichbar ist und der SSH-Port 22 geöffnet ist.
```
ping SERVER_NAME
```
```
traceroute SERVER_NAME
```
```
echo "" | nc SERVER_NAME 22
```
Wenn das nicht funktioniert, liegt das Problem möglicherweise in der Netzwerkschicht und nicht bei SSH.
Sehen Sie sich die clientseitige Debugausgabe an.
1. Aktivieren Sie die Detaillierung des SSH-Protokolls.
```
ssh -v SERVER_NAME -i ~/.ssh/id_ecdsa
```
  Der Befehl gibt die Debugausgabe aus, die die wichtigsten Ereignisse des clientseitigen SSH-Protokolls enthält.
  
  Die folgende Beispielausgabe zeigt, dass der Client seinen Schlüssel gesendet, aber der Server ihn abgelehnt hat. Der Server hat die Authentifizierung aufgefordert, mit einem anderen öffentlichen Schlüssel fortzufahren, aber der Client hat keine zusätzlichen Schlüssel anzubieten.
```
.. .. ..
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 den Fehler zu finden. Solange Sie nicht per SSH auf Ihren Server zugreifen können, führen Sie die folgenden Schritte über die interaktive serielle Konsole aus.
Prüfen Sie die serverseitige Debugausgabe.
1. Aktuelle SSH-Einstellungen aufrufen
```
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, damit die Änderungen übernommen werden.
```
service sshd restart
```
4. Führen Sie auf der Clientseite den Befehl ssh aus und extrahieren Sie die 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: Der Beginn 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 mit Lesezugriffsberechtigungen (Flag 400) festgelegt ist. Andernfalls wird sie vom SSH-Client nicht akzeptiert.

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 des entsprechenden Nutzers (~/.ssh/authorized_keys) 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
```