Diese Seite wurde von der Cloud Translation API übersetzt.

Fehler beim Zugriff beheben

Auf dieser Seite finden Sie Tipps zur Fehlerbehebung bei Zugriffsproblemen der 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 eines der folgende Fehler:

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.

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 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 Debug-Ausgabe aus, die die wichtigsten Ereignisse des clientseitigen SSH-Protokolls enthält.
  
  Die folgende Beispielausgabe zeigt, dass die Client hat seinen Schlüssel gesendet, aber der Server hat ihn abgelehnt. 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 Ausgabe von strace auf Fehler im Zusammenhang mit dem Kern Problem.
  
  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. Rufen Sie die aktuellen SSH-Einstellungen auf.
```
grep -v "^#" /etc/ssh/sshd_config | grep -v "^$"
```
2. Legen Sie die folgenden Parameter fest, um detaillierte Informationen zu SSH zu erhalten in der Datei /etc/ssh/sshd_config, um detaillierte Informationen zu erhalten.
```
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-Nachrichten aus den Protokollen:
```
grep sshd /var/log/messages
```
  Alternativ können Sie alle relevanten Nachrichten für den Zeitraum mithilfe der folgenden Befehl:
```
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 in 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
```

Gehen Sie so vor, um diese Probleme zu 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 folgenden Befehl aus, um das schreibgeschützte Flag für den verwendeten privaten Schlüssel festzulegen: Befehl:
```
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 der SSH-Algorithmus. Die server- und clientseitigen Debug-Ausgaben können auf ein solches Problem hinweisen. In der Regel sind die man-Seiten für ssh und sshd_config liefern die Details zum Aufrechterhalten der erforderlichen Konfiguration. Um beispielsweise Schlüsselaustauschalgorithmen oder Chiffren verwenden, verwenden Sie die folgenden Befehle:
```
# Find key exchange algorithms
ssh -Q kex
# Find the symmetric encryption ciphers
ssh -Q cipher
```