Sichere SSH-Verbindungen in Red Hat Enterprise Linux

Red Hat Enterprise LinuxRed Hat Enterprise LinuxBeginner
Jetzt üben

💡 Dieser Artikel wurde von AI-Assistenten übersetzt. Um die englische Version anzuzeigen, können Sie hier klicken

Einführung

In diesem Labor erhalten Sie praktische Erfahrung in der Konfiguration und Absicherung von SSH-Verbindungen, einer grundlegenden Fähigkeit für die Verwaltung von entfernten Linux-Systemen. Sie beginnen mit dem Erlernen des Zugriffs auf entfernte Systeme über SSH, dem Verständnis der Client-Server-Architektur und grundlegender Verbindungskommandos. Dies beinhaltet die Überprüfung der SSH-Client-Installation, die Verbindung zu einem Remote-Host, die Bearbeitung von Host-Authentifizierungsaufforderungen und das Ein- und Ausloggen in entfernte Systeme.

Aufbauend auf diesem Fundament werden Sie sich dann mit fortgeschritteneren Themen wie dem Generieren und Verwenden von SSH-Schlüsselpaaren für die passwortlose Authentifizierung, der effektiven Verwaltung dieser Schlüssel mit ssh-agent und der Fehlerbehebung bei häufigen SSH-Verbindungsproblemen befassen. Schließlich lernen Sie, die SSH-Client-Konfigurationen für verbesserte Effizienz anzupassen und die Sicherheit Ihres OpenSSH-Servers zu erhöhen, indem Sie den Root-Login und die Passwort-Authentifizierung deaktivieren, um einen robusten und sicheren Remote-Zugriff zu gewährleisten.

Dies ist ein Guided Lab, das schrittweise Anweisungen bietet, um Ihnen beim Lernen und Üben zu helfen. Befolgen Sie die Anweisungen sorgfältig, um jeden Schritt abzuschließen und praktische Erfahrungen zu sammeln. Historische Daten zeigen, dass dies ein Labor der Stufe Anfänger mit einer Abschlussquote von 88% ist. Es hat eine positive Bewertungsrate von 100% von den Lernenden erhalten.

Zugriff auf entfernte Systeme mit SSH

In diesem Schritt lernen Sie, wie Sie auf entfernte Systeme über SSH (Secure Shell) zugreifen. SSH ist ein kryptografisches Netzwerkprotokoll zum sicheren Betrieb von Netzwerkdiensten über ein unsicheres Netzwerk. Es stellt einen sicheren Kanal über ein unsicheres Netzwerk bereit, indem es eine Client-Server-Architektur verwendet, die einen SSH-Client mit einem SSH-Server verbindet.

Hinweis: In dieser Laboumgebung sind möglicherweise bereits einige Sicherheitsfunktionen wie Einschränkungen für den Root-Login zu Sicherheitszwecken konfiguriert. Dies ist normal und demonstriert bewährte Praktiken in der Anwendung.

Zuerst verbinden Sie sich über SSH mit dem lokalen System. Dies demonstriert die SSH Client-Server-Architektur, selbst wenn Sie sich mit derselben Maschine verbinden. Sie verwenden den Befehl ssh, um sich mit localhost zu verbinden.

Die grundlegende Syntax für ssh lautet:
ssh [Benutzername]@[Hostname_oder_IP]

Wenn Sie keinen Benutzernamen angeben, versucht SSH, sich mit Ihrem aktuellen lokalen Benutzernamen anzumelden. In diesem Fall ist Ihr lokaler Benutzername labex.

Versuchen wir, uns mit localhost unter Verwendung Ihres aktuellen Benutzernamens zu verbinden:

ssh localhost

Wenn Sie sich zum ersten Mal verbinden, fordert SSH Sie auf, die Authentizität des Hosts zu bestätigen. Dies ist eine Sicherheitsmaßnahme zur Verhinderung von Man-in-the-Middle-Angriffen. Geben Sie yes ein und drücken Sie die Eingabetaste.

Die Authentizität des Hosts 'localhost (127.0.0.1)' kann nicht festgestellt werden.
ED25519-Schlüssel-Fingerabdruck ist SHA256:h5k1mmPFylpxUCsKx+Mf8rN4wOrk9TmyRfzTvGWRm7A.
Dieser Schlüssel ist unter keinem anderen Namen bekannt.
Sind Sie sicher, dass Sie die Verbindung fortsetzen möchten (ja/nein/[Fingerabdruck])? yes
Warnung: 'localhost' (ED25519) wurde dauerhaft der Liste der bekannten Hosts hinzugefügt.
Kennwort für 'labex@localhost':

Sie werden nach dem Kennwort des Benutzers labex gefragt. Geben Sie labex ein und drücken Sie die Eingabetaste.

Kennwort für 'labex@localhost':
Letzter Login: Mo 09. Jun 01:34:39 2025 von 47.251.66.143
[labex@host ~]$

Sie sind nun über SSH bei localhost angemeldet. Beachten Sie, dass Ihre Eingabeaufforderung möglicherweise [labex@localhost ~]$ anzeigt, was darauf hinweist, dass Sie über SSH verbunden sind.

Um die SSH-Sitzung zu beenden, verwenden Sie den Befehl exit:

exit
Abmeldung
Verbindung zu localhost geschlossen.
[labex@host ~]$

Versuchen wir nun, uns als Benutzer root mit localhost zu verbinden. Beachten Sie, dass in dieser Umgebung der Root-Login möglicherweise standardmäßig aus Sicherheitsgründen deaktiviert ist.

ssh root@localhost

Sie werden nach dem Root-Kennwort gefragt. Möglicherweise erhalten Sie jedoch eine Fehlermeldung "Zugriff verweigert", wenn der Root-Login deaktiviert ist:

Kennwort für 'root@localhost':
Zugriff verweigert, bitte versuchen Sie es erneut.
Kennwort für 'root@localhost':
Zugriff verweigert, bitte versuchen Sie es erneut.
Kennwort für 'root@localhost':

Wenn der Root-Login deaktiviert ist, ist dies das erwartete Verhalten und demonstriert eine bewährte Sicherheitsmethode. Sie können Strg+C drücken, um den Verbindungsversuch abzubrechen.

SSH kann auch verwendet werden, um einen einzelnen Befehl auf einem Remotesystem auszuführen, ohne eine interaktive Shell zu öffnen. Dies ist nützlich für schnelle Prüfungen oder Automatisierungen.

Führen wir den Befehl hostname auf localhost als Benutzer labex aus:

ssh labex@localhost hostname

Sie werden nach dem Kennwort des Benutzers labex gefragt. Geben Sie labex ein und drücken Sie die Eingabetaste.

Kennwort für 'labex@localhost':
6846375f1c0e35fea6cb03e6
[labex@host ~]$

Der Befehl hostname wurde über SSH ausgeführt, und sein Ausgabe wurde auf Ihrem lokalen Terminal angezeigt. Sie wurden nicht in eine interaktive Shell versetzt.

Schließlich untersuchen wir, wie SSH bekannte Hosts verwaltet. Wenn Sie sich mit einem neuen SSH-Server verbinden, wird sein öffentlicher Schlüssel-Fingerabdruck in Ihre Datei ~/.ssh/known_hosts hinzugefügt. Diese Datei hilft Ihrem SSH-Client, die Identität des Servers bei zukünftigen Verbindungen zu verifizieren.

Sie können den Inhalt Ihrer Datei ~/.ssh/known_hosts anzeigen:

cat ~/.ssh/known_hosts
localhost ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHvl7dcZkvMNOr3cjKjlR2/JgFbGpURThT/bHnLZN6gG
localhost ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCynhy3601o9ZSGZoY0KB/QSonk5ykod2Tb7sCAqVn4ZgTCwd96BhPjJLPNQ6ldNASo1e7EzfT4BUjG5T0ZDRhgaI65qmDwITWipTWUfmYT5XoScyf6NDhcRxYiJwztFEkOvLcPhelS6UXj5Z7HdmYH4Nc5wiF00Wah3Jc0/2CfQsFZCXTn/7Kp8KKbBbPqPzr2R3WIULEacOxx9HKVv+2TvYg/OHZz40hTsr1c68DD7h5PMBNe21YB3HLRRk2LQEC7v7BFD+DCek9GNR66JBjbLDljtwWCaPCY0UntBjjvJ3W2LhX5RDZQHV/iaUSj2tEXnvPt9KSqGfBS91D12dBXyOmWVnTpvvI17BdDkEeefas2Uz4d7Bv/PDxZR6IKkaIGQ/ZnRhSEhBNvfqlBGqkOhRr6jQJK+rQMnsZCT6OEgW7osWzkw5Bs1wY/RNToeQqrRMclqffO9plFI688N2iT86+nxrvBVZg4yMMm2J1lleaBvinXCB8jE6lrtwoAdgk=
localhost ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBKYWY8Ty6TrbQS/0fUljBWuUpkyPCS/5P6ZwxhSYsqjRBIprMANI/JQotZqHYq2w3b2X/n8O+J3/WuIB6XMl1f4=

Diese Einträge bestätigen, dass Ihr Client mehrere öffentliche Schlüssel für localhost (ED25519, RSA und ECDSA) aufgezeichnet hat. Der SSH-Server unterstützt möglicherweise mehrere Schlüsseltypen für die Kompatibilität. Sollten sich diese Server-Schlüssel jemals unerwartet ändern, wird Sie SSH warnen, was eine wichtige Sicherheitsfunktion darstellt.

Generieren und Verwenden von SSH-Schlüsselpaaren für die passwortlose Authentifizierung

In diesem Schritt lernen Sie, wie Sie SSH-Schlüsselpaare generieren und für die passwortlose Authentifizierung verwenden. Die SSH-Schlüsselbasierte Authentifizierung ist eine sicherere und bequemere Alternative zur Passwort-Authentifizierung. Anstatt jedes Mal ein Passwort einzugeben, wenn Sie eine Verbindung herstellen, verwenden Sie ein Paar kryptografischer Schlüssel: einen privaten Schlüssel (der auf Ihrem lokalen Rechner geheim gehalten wird) und einen öffentlichen Schlüssel (der auf dem Remote-Server abgelegt wird).

Zuerst müssen Sie ein SSH-Schlüsselpaar generieren. Dazu verwenden Sie den Befehl ssh-keygen. Standardmäßig erstellt ssh-keygen ein RSA-Schlüsselpaar und speichert den privaten Schlüssel in ~/.ssh/id_rsa und den öffentlichen Schlüssel in ~/.ssh/id_rsa.pub.

Führen Sie den Befehl ssh-keygen aus:

ssh-keygen

Sie werden nach einigen Optionen gefragt:

Erstellung des öffentlichen/privaten RSA-Schlüsselpaares.
Datei, in der der Schlüssel gespeichert werden soll (/home/labex/.ssh/id_rsa):

Drücken Sie die Eingabetaste, um den Standardpfad (/home/labex/.ssh/id_rsa) zu übernehmen.

Passphrase eingeben (leer für keine Passphrase):

Für dieses Labor drücken Sie zweimal die Eingabetaste, um die Passphrase leer zu lassen. Obwohl die Verwendung einer Passphrase in realen Szenarien empfohlen wird, um eine zusätzliche Sicherheitsebene hinzuzufügen, überspringen wir sie hier der Einfachheit halber und um die passwortlose Authentifizierung direkt zu demonstrieren.

Passphrase eingeben (leer für keine Passphrase):
Passphrase nochmals eingeben:
Ihre Identifizierung wurde in /home/labex/.ssh/id_rsa gespeichert
Ihr öffentlicher Schlüssel wurde in /home/labex/.ssh/id_rsa.pub gespeichert
Der Schlüssel-Fingerabdruck lautet:
SHA256:QoV7pNBFu1kafGP3VJhpZuIdr1zc+qamJ1C2YAadgNY labex@6846375f1c0e35fea6cb03e6
Das Zufallsbild des Schlüssels ist:
+---[RSA 3072]----+
|     . *=o .   +.|
|    . =oE.o . O. |
|     o.++.=..*.+.|
|     .o .O+o+o. =|
|      ..So + o.+ |
|       .  . . +  |
|           .   . |
|            . o o|
|            .=.o |
+----[SHA256]-----+

Überprüfen Sie nun, ob die Schlüsseldateien im Verzeichnis ~/.ssh/ erstellt wurden:

ls -l ~/.ssh/
gesamt 16
-rw------- 1 labex labex 2622 Jun  9 01:37 id_rsa
-rw-r--r-- 1 labex labex  584 Jun  9 01:37 id_rsa.pub
-rw------- 1 labex labex  825 Jun  9 01:35 known_hosts
-rw-r--r-- 1 labex labex   91 Jun  9 01:35 known_hosts.old

Sie sollten id_rsa (Ihren privaten Schlüssel) und id_rsa.pub (Ihren öffentlichen Schlüssel) sehen. Beachten Sie die Berechtigungen: id_rsa hat rw------- (nur Lesen/Schreiben für den Besitzer), was für die Sicherheit entscheidend ist. Sie sehen möglicherweise auch known_hosts.old, eine Sicherung der vorherigen known_hosts-Datei.

Als Nächstes müssen Sie Ihren öffentlichen Schlüssel kopieren, um die passwortlose Authentifizierung zu aktivieren. Der Befehl ssh-copy-id ist hierfür konzipiert. Er hängt Ihren öffentlichen Schlüssel an die Datei ~/.ssh/authorized_keys an, sodass Sie sich ohne Passwort anmelden können.

Führen Sie den Befehl ssh-copy-id aus und geben Sie den Benutzernamen und den Hostnamen an:

ssh-copy-id labex@localhost

Sie werden nach dem Kennwort des Benutzers labex gefragt. Geben Sie labex ein und drücken Sie die Eingabetaste.

/usr/bin/ssh-copy-id: INFO: Quelle der zu installierenden Schlüssel(e): "/home/labex/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: Versuch der Anmeldung mit den neuen Schlüssel(n), um bereits installierte zu filtern
/usr/bin/ssh-copy-id: INFO: 1 Schlüssel(e) müssen noch installiert werden -- wenn Sie jetzt aufgefordert werden, werden die neuen Schlüssel installiert
Kennwort für 'labex@localhost':

Anzahl der hinzugefügten Schlüssel(e): 1

Versuchen Sie nun, sich mit: "ssh 'labex@localhost'" bei der Maschine anzumelden, und prüfen Sie, ob nur die gewünschten Schlüssel(e) hinzugefügt wurden.

Die Ausgabe des Befehls bestätigt, dass ein Schlüssel hinzugefügt wurde. Versuchen Sie nun, sich als Benutzer labex bei localhost anzumelden, ohne ein Passwort anzugeben:

ssh labex@localhost

Wenn alles korrekt konfiguriert ist, sollten Sie sich über SSH anmelden, ohne nach einem Passwort gefragt zu werden.

Letzter Login: Mo 09. Jun 01:37:39 2025 von 47.251.66.143
[labex@host ~]$

Sie haben die passwortlose SSH-Authentifizierung mit Schlüsselpaaren erfolgreich konfiguriert!

Um die Remotesitzung zu beenden, geben Sie exit ein:

exit
exit
Verbindung zu localhost geschlossen.
[labex@host ~]$

Verwalten von SSH-Schlüsseln mit ssh-agent

In diesem Schritt lernen Sie, wie Sie Ihre SSH-Schlüssel mit ssh-agent verwalten. Der ssh-agent ist ein Programm, das im Hintergrund läuft und Ihre privaten Schlüssel im Arbeitsspeicher hält. Dies ist besonders nützlich, wenn Ihre privaten Schlüssel durch eine Passphrase geschützt sind. Anstatt die Passphrase jedes Mal einzugeben, wenn Sie den Schlüssel verwenden, geben Sie sie einmal ein, wenn Sie den Schlüssel zum ssh-agent hinzufügen, und dann kümmert sich der Agent für den Rest Ihrer Sitzung um die Authentifizierung.

Obwohl Sie im vorherigen Schritt einen Schlüssel ohne Passphrase generiert haben, erstellen wir nun einen neuen Schlüssel mit einer Passphrase, um die Nützlichkeit von ssh-agent zu demonstrieren.

Generieren Sie zunächst ein neues SSH-Schlüsselpaar mit einer Passphrase. Wir nennen diesen Schlüssel id_rsa_passphrase, um ihn vom Standard-Schlüssel id_rsa zu unterscheiden.

ssh-keygen -f ~/.ssh/id_rsa_passphrase

Sie werden aufgefordert, eine Passphrase einzugeben. Verwenden Sie für dieses Labor mypassphrase als Passphrase.

Erstellung des öffentlichen/privaten RSA-Schlüsselpaares.
Passphrase eingeben (leer für keine Passphrase): mypassphrase
Passphrase nochmals eingeben: mypassphrase
Ihre Identifizierung wurde in /home/labex/.ssh/id_rsa_passphrase gespeichert
Ihr öffentlicher Schlüssel wurde in /home/labex/.ssh/id_rsa_passphrase.pub gespeichert
Der Schlüssel-Fingerabdruck lautet:
SHA256:BuSxVlJb1lsiUFi2I5DAvyL01fJ5d480LT86dgtcHEg labex@6846375f1c0e35fea6cb03e6
Das Zufallsbild des Schlüssels ist:
+---[RSA 3072]----+
|   ...=o+=*. E   |
|    .o.*.=..+ o  |
|     .=.o o. = . |
|  .  .+... .. . .|
| . . . +S.     + |
|  . o ..o . o * .|
|   . .   . . = * |
|             oooo|
|            ..+.o|
+----[SHA256]-----+

Hinweis: Wenn Sie versehentlich die Eingabetaste drücken, ohne eine Passphrase einzugeben, wird der Schlüssel ohne Passphrase erstellt. In diesem Fall können Sie die Dateien löschen und den Befehl erneut ausführen, wobei Sie sicherstellen, dass Sie mypassphrase eingeben, wenn Sie dazu aufgefordert werden.

Kopieren wir nun diesen neuen öffentlichen Schlüssel nach localhost, damit Sie ihn für die Authentifizierung verwenden können.

ssh-copy-id -i ~/.ssh/id_rsa_passphrase.pub labex@localhost

Da Sie bereits eine passwortlose Authentifizierung mit Ihrem Standardschlüssel eingerichtet haben, wird der Befehl möglicherweise nicht nach einem Passwort fragen und Ihre vorhandene Authentifizierung verwenden:

/usr/bin/ssh-copy-id: INFO: Quelle der zu installierenden Schlüssel(e): "/home/labex/.ssh/id_rsa_passphrase.pub"
/usr/bin/ssh-copy-id: INFO: Versuch der Anmeldung mit den neuen Schlüssel(n), um bereits installierte zu filtern
/usr/bin/ssh-copy-id: INFO: 1 Schlüssel(e) müssen noch installiert werden -- wenn Sie jetzt aufgefordert werden, werden die neuen Schlüssel installiert

Anzahl der hinzugefügten Schlüssel(e): 1

Versuchen Sie nun, sich mit: "ssh 'labex@localhost'" bei der Maschine anzumelden, und prüfen Sie, ob nur die gewünschten Schlüssel(e) hinzugefügt wurden.

Versuchen Sie nun, eine Verbindung zu localhost mit diesem neuen Schlüssel herzustellen. Sie müssen die private Schlüsseldatei mit der Option -i angeben.

ssh -i ~/.ssh/id_rsa_passphrase labex@localhost

Wenn Sie eine Passphrase für den Schlüssel festgelegt haben, werden Sie danach gefragt. Wenn Sie den Schlüssel versehentlich ohne Passphrase erstellt haben (wie im Beispielausgabe gezeigt), werden Sie direkt angemeldet:

Letzter Login: Mo 09. Jun 01:39:25 2025 von 47.251.66.143
[labex@host ~]$

Sie sind angemeldet. Beenden Sie nun die Sitzung:

exit
exit
Verbindung zu localhost geschlossen.
[labex@host ~]$

Hinweis: Wenn Ihr Schlüssel keine Passphrase hat, können Sie trotzdem mit der ssh-agent-Demonstration fortfahren, um zu verstehen, wie sie funktioniert, auch wenn in diesem Fall keine Passphrase abgefragt wird.

Starten Sie zunächst den ssh-agent in Ihrer aktuellen Shell-Sitzung. Der Befehl eval wird verwendet, um die Umgebungsvariablen korrekt festzulegen, die ssh-agent ausgibt.

eval "$(ssh-agent)"
Agent-PID 1024

Die Ausgabe zeigt die Prozess-ID (PID) des ssh-agent.

Als Nächstes fügen Sie Ihren privaten Schlüssel (id_rsa_passphrase) zum ssh-agent hinzu.

ssh-add ~/.ssh/id_rsa_passphrase

Wenn Ihr Schlüssel eine Passphrase hat, werden Sie danach gefragt. Wenn nicht, wird der Schlüssel direkt hinzugefügt:

Identität hinzugefügt: /home/labex/.ssh/id_rsa_passphrase (labex@6846375f1c0e35fea6cb03e6)

Nachdem der Schlüssel zum ssh-agent hinzugefügt wurde, versuchen Sie erneut, eine Verbindung zu localhost mit demselben Schlüssel herzustellen.

ssh -i ~/.ssh/id_rsa_passphrase labex@localhost

Sie sollten sich verbinden können, ohne nach einer Passphrase gefragt zu werden (ob Ihr Schlüssel eine hat oder nicht, da er jetzt vom Agenten verwaltet wird):

Letzter Login: Mo 09. Jun 01:39:49 2025 von 127.0.0.1
[labex@host ~]$

Sie haben ssh-agent erfolgreich verwendet, um Ihren SSH-Schlüssel zu verwalten.

Wichtiger Hinweis: Die Umgebungsvariablen von ssh-agent sind nur in der Shell-Sitzung verfügbar, in der Sie sie gestartet haben. Wenn Sie sich in einer SSH-Sitzung befinden, müssen Sie zurück zu Ihrer lokalen Shell wechseln, um ssh-add-Befehle zu verwenden.

Beenden Sie zuerst die SSH-Sitzung:

exit
exit
Verbindung zu localhost geschlossen.
[labex@host ~]$

Um die derzeit im ssh-agent geladenen Schlüssel anzuzeigen, können Sie ssh-add -l verwenden:

ssh-add -l

Wenn der Agent läuft und Schlüssel geladen hat, sehen Sie eine Ausgabe wie:

3072 SHA256:BuSxVlJb1lsiUFi2I5DAvyL01fJ5d480LT86dgtcHEg /home/labex/.ssh/id_rsa_passphrase (RSA)

Wenn Sie jedoch eine Fehlermeldung wie "Could not open a connection to your authentication agent" sehen, bedeutet dies, dass die Agent-Umgebungsvariablen in Ihrer aktuellen Sitzung nicht gesetzt sind.

Um alle Identitäten vom ssh-agent zu entfernen, verwenden Sie ssh-add -D:

ssh-add -D

Wenn der Agent zugänglich ist, sehen Sie:

Alle Identitäten entfernt.

Wenn Sie jedoch "Could not open a connection to your authentication agent" sehen, bedeutet dies, dass der Agent in Ihrer aktuellen Sitzung nicht verfügbar ist.

Wenn Sie nun erneut eine Verbindung herstellen und Ihr Schlüssel eine Passphrase hat, werden Sie danach gefragt, da der Schlüssel vom Agenten entfernt wurde:

ssh -i ~/.ssh/id_rsa_passphrase labex@localhost

Wenn Ihr Schlüssel eine Passphrase hat, sehen Sie:

Passphrase für Schlüssel '/home/labex/.ssh/id_rsa_passphrase' eingeben:

Wenn Ihr Schlüssel keine Passphrase hat, können Sie sich trotzdem direkt verbinden. Drücken Sie Strg+C, um den Verbindungsversuch abzubrechen, wenn Sie nach einer Passphrase gefragt werden.

Schließlich können Sie den ssh-agent-Prozess mit ssh-agent -k beenden:

ssh-agent -k

Wenn die Umgebungsvariable SSH_AGENT_PID nicht gesetzt ist, sehen Sie möglicherweise:

SSH_AGENT_PID nicht gesetzt, Agent kann nicht beendet werden

Dies ist normal, wenn der Agent in einer anderen Shell-Sitzung gestartet wurde oder wenn die Umgebungsvariablen nicht ordnungsgemäß exportiert wurden.

SSH-Verbindungsprobleme beheben

In diesem Schritt lernen Sie, häufige SSH-Verbindungsprobleme zu beheben. Wenn SSH-Verbindungen fehlschlagen, kann es schwierig sein, das genaue Problem zu identifizieren. Der Befehl ssh bietet ausführliche Ausgabeoptionen, die bei der Diagnose von Problemen helfen, indem detaillierte Informationen über den Verbindungsprozess angezeigt werden.

Der Befehl ssh bietet drei Detaillierungsstufen: -v, -vv und -vvv. Jede zusätzliche v erhöht die Menge der angezeigten Debugging-Informationen.

Beginnen wir damit, eine Verbindung zu einem nicht existierenden Port auf localhost herzustellen, um Verbindungsfehler zu demonstrieren und die Debugging-Ausgabe zu sehen.

Versuchen Sie zunächst die Verbindung zu Port 2222 (der wahrscheinlich nicht aktiv ist) mit -v (ausführlich):

ssh -v -p 2222 labex@localhost

Sie erhalten eine Ausgabe ähnlich dieser, die darauf hinweist, dass die Verbindung abgelehnt wurde:

OpenSSH_8.7p1, OpenSSL 3.0.1 14 Dec 2021
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/01-training.conf
debug1: /etc/ssh/ssh_config.d/01-training.conf line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: /etc/ssh/ssh_config.d/50-redhat.conf line 3: Applying options for *
debug1: Connecting to localhost [127.0.0.1] port 2222.
ssh: connect to host localhost port 2222: Connection refused

Versuchen Sie nun die Verbindung mit -vv (ausführlicher):

ssh -vv -p 2222 labex@localhost

Die Ausgabe wird detaillierter und enthält zusätzliche Debugging-Meldungen:

OpenSSH_8.7p1, OpenSSL 3.0.1 14 Dec 2021
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/01-training.conf
debug1: /etc/ssh/ssh_config.d/01-training.conf line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: /etc/ssh/ssh_config.d/50-redhat.conf line 3: Applying options for *
debug2: resolving "localhost" port 2222
debug2: ssh_connect_direct: entering
debug1: Connecting to localhost [127.0.0.1] port 2222.
debug1: connect to address 127.0.0.1 port 2222: Connection refused
ssh: connect to host localhost port 2222: Connection refused

Schließlich versuchen Sie es mit -vvv (maximal ausführlich):

ssh -vvv -p 2222 labex@localhost

Diese Stufe liefert die maximalen Debugging-Informationen, die bei komplexen Problemen zwar umfangreich, aber sehr hilfreich sein können.

OpenSSH_8.7p1, OpenSSL 3.0.1 14 Dec 2021
debug3: ssh_connect_internal: entering
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/01-training.conf
debug1: /etc/ssh/ssh_config.d/01-training.conf line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: /etc/ssh/ssh_config.d/50-redhat.conf line 3: Applying options for *
debug2: resolving "localhost" port 2222
debug2: ssh_connect_direct: entering
debug1: Connecting to localhost [127.0.0.1] port 2222.
debug1: connect to address 127.0.0.1 port 2222: Connection refused
ssh: connect to host localhost port 2222: Connection refused

In diesem Fall zeigt der Fehler „Connection refused“ deutlich an, dass kein SSH-Server auf Port 2222 läuft.

Simulieren wir nun ein häufiges Problem: ein geänderter Host-Schlüssel. Im ersten Schritt haben Sie sich mit localhost verbunden, und sein öffentlicher Schlüssel wurde in Ihre Datei ~/.ssh/known_hosts aufgenommen. Wenn sich der SSH-Server-Schlüssel ändern würde (z. B. aufgrund eines Server-Neubaus oder eines böswilligen Angriffs), würde Ihr SSH-Client diesen Unterschied erkennen und die Verbindung verweigern.

Um dies zu simulieren, ändern wir absichtlich den Eintrag in known_hosts für localhost, um ihn ungültig zu machen.

Öffnen Sie zunächst die Datei ~/.ssh/known_hosts mit nano:

nano ~/.ssh/known_hosts

Sie sehen mehrere Zeilen mit verschiedenen Schlüsseltypen:

...

Wählen Sie eine der Zeilen zur Änderung. In diesem Beispiel ändern wir den ED25519-Schlüssel (die erste Zeile). Ändern Sie einige Zeichen in der langen Schlüsselzeichenkette (z. B. ändern Sie das letzte Zeichen von G in A). Achten Sie darauf, dass Sie nicht die gesamte Zeile oder andere Teile der Datei löschen.

Speichern Sie die Datei, indem Sie Strg+X, dann Y zum Bestätigen des Speicherns und die Eingabetaste zum Bestätigen des Dateinamens drücken.

Versuchen Sie nun erneut, eine Verbindung zu localhost herzustellen:

ssh labex@localhost

Sie erhalten eine Warnung über einen geänderten Host-Schlüssel:

...

Dies ist eine kritische Sicherheitswarnung. Wenn Sie dies in einem realen Szenario antreffen, sollten Sie untersuchen, warum sich der Host-Schlüssel geändert hat. Wenn es sich um eine legitime Änderung handelt (z. B. Server-Neuinstallation), müssen Sie den alten Eintrag aus known_hosts entfernen.

Um dies zu beheben, können Sie entweder ~/.ssh/known_hosts manuell bearbeiten und die fehlerhafte Zeile entfernen oder ssh-keygen -R verwenden, um den Eintrag für localhost zu entfernen.

Löschen wir den falschen Eintrag mit ssh-keygen -R:

ssh-keygen -R localhost
...

Versuchen Sie nun erneut, eine Verbindung zu localhost herzustellen. Sie werden aufgefordert, die Authentizität des Hosts zu bestätigen, genau wie beim ersten Verbindungsversuch.

ssh labex@localhost
...

Sie sind nun wieder erfolgreich über die schlüsselbasierte Authentifizierung verbunden.

Beenden Sie die Sitzung:

exit
...

SSH-Client-Konfiguration anpassen

In diesem Schritt erfahren Sie, wie Sie Ihre SSH-Client-Konfigurationen mithilfe der Datei ~/.ssh/config anpassen. Diese Datei ermöglicht es Ihnen, Aliasnamen und spezifische Verbindungsparameter für verschiedene Remote-Hosts zu definieren, wodurch Ihre SSH-Befehle vereinfacht und konsistenter gestaltet werden.

Die Datei ~/.ssh/config ist ein leistungsstarkes Werkzeug zur Verwaltung Ihrer SSH-Verbindungen. Sie können verschiedene Optionen wie den Benutzernamen, die zu verwendende private Schlüsseldatei, die Portnummer und sogar erweiterte Einstellungen wie Proxy-Befehle angeben.

Erstellen oder öffnen Sie zunächst die Datei ~/.ssh/config. Falls sie nicht existiert, erstellt nano sie.

nano ~/.ssh/config

Fügen Sie die folgende Konfiguration in die Datei ein. Diese Konfiguration definiert einen Alias localhost_labex für die Verbindung zu localhost als Benutzer labex und einen Alias localhost_root für die Verbindung als Benutzer root. Sie gibt auch explizit das IdentityFile für den Benutzer labex an, um den in einem vorherigen Schritt generierten Schlüssel id_rsa zu verwenden.

Host localhost_labex
    HostName localhost
    User labex
    IdentityFile ~/.ssh/id_rsa

Host localhost_root
    HostName localhost
    User root

Speichern Sie die Datei, indem Sie Strg+X, dann Y zum Bestätigen des Speicherns und die Eingabetaste zum Bestätigen des Dateinamens drücken.

Versuchen wir nun, eine Verbindung zu localhost mit diesen neuen Aliasnamen herzustellen.

Verbinden Sie sich als Benutzer labex mit dem Alias localhost_labex:

ssh localhost_labex

Da Sie IdentityFile ~/.ssh/id_rsa konfiguriert haben und id_rsa keine Passphrase besitzt, sollten Sie sich ohne Passwort-Abfrage anmelden.

Letzter Login: Mo 09. Jun 01:54:16 2025 von 47.251.66.143
[labex@host ~]$

Beenden Sie die Sitzung:

exit
exit
Verbindung zu localhost geschlossen.
[labex@host ~]$

Verbinden Sie sich nun als Benutzer root mit dem Alias localhost_root:

ssh localhost_root

Sie werden nach dem Passwort des Benutzers root gefragt. Da die Anmeldung als root in dieser Umgebung deaktiviert ist, erhalten Sie eine Fehlermeldung "Permission denied":

root@localhost's password:
Permission denied, please try again.
root@localhost's password:

Drücken Sie Strg+C, um die Verbindung abzubrechen:

^C

Dies zeigt, dass der SSH-Konfigurationsalias funktioniert, die Verbindung jedoch aufgrund der Sicherheitsrichtlinie, die die Anmeldung als root deaktiviert, fehlschlägt.

Wie Sie sehen, vereinfacht die Verwendung der Datei ~/.ssh/config Ihre SSH-Befehle, indem gängige Verbindungsparameter vorkonfiguriert werden.

Fügen wir einen weiteren Eintrag hinzu, um die Angabe eines anderen Ports zu demonstrieren. Während localhost den Standard-SSH-Port (22) verwendet, zeigt dieses Beispiel, wie Sie ihn konfigurieren würden, wenn er anders wäre.

Öffnen Sie die Datei ~/.ssh/config erneut:

nano ~/.ssh/config

Fügen Sie den folgenden Eintrag hinzu. Dies erstellt einen Alias localhost_port_example, der den Port explizit auf 2222 setzt. (Hinweis: localhost hört tatsächlich nicht auf Port 2222, daher wird diese Verbindung fehlschlagen, aber es demonstriert die Konfiguration.)

Host localhost_labex
    HostName localhost
    User labex
    IdentityFile ~/.ssh/id_rsa

Host localhost_root
    HostName localhost
    User root

Host localhost_port_example
    HostName localhost
    Port 2222
    User labex

Speichern Sie die Datei.

Versuchen Sie nun, eine Verbindung mit dem Alias localhost_port_example herzustellen:

ssh localhost_port_example

Diese Verbindung wird fehlschlagen, da localhost nicht auf Port 2222 lauscht, aber es zeigt, wie Sie einen benutzerdefinierten Port in Ihrer SSH-Konfiguration angeben können.

ssh: connect to host localhost port 2222: Cannot assign requested address

Weitere Informationen zu typischen Fehlern finden Sie unter diesem Link:
            https://red.ht/support_rhel_ssh

Sie können Ihre aktuelle SSH-Konfiguration anzeigen, um alle definierten Hosts zu sehen:

cat ~/.ssh/config
...

Schließlich bereinigen wir die Datei ~/.ssh/config, indem wir den Eintrag localhost_port_example entfernen.

Öffnen Sie die Datei ~/.ssh/config:

nano ~/.ssh/config

Löschen Sie den Block Host localhost_port_example. Die Datei sollte wie folgt aussehen:

Host localhost_labex
    HostName localhost
    User labex
    IdentityFile ~/.ssh/id_rsa

Host localhost_root
    HostName localhost
    User root

Speichern Sie die Datei.

Verständnis der OpenSSH-Server-Sicherheitskonfiguration

In diesem Schritt lernen Sie die bewährten Sicherheitsmethoden für OpenSSH-Server kennen, indem Sie die aktuelle Sicherheitskonfiguration untersuchen. Sie werden verstehen, wie Root-Login-Einschränkungen und Passwort-Authentifizierungseinstellungen Ihren Server vor unbefugtem Zugriff schützen.

Hinweis: In diesem Lab-Umfeld sind die Sicherheitseinstellungen bereits korrekt konfiguriert, um bewährte Methoden zu demonstrieren. Dieser Schritt konzentriert sich auf das Verständnis und die Überprüfung dieser Sicherheitsmaßnahmen, anstatt sie zu ändern.

Verständnis der Root-Login-Sicherheit

Die direkte Anmeldung als Root über SSH wird im Allgemeinen abgeraten, da das Root-Konto über vollständige administrative Berechtigungen verfügt. Wenn ein Angreifer Zugriff auf das Root-Konto erhält, hat er die vollständige Kontrolle über Ihr System. Es ist sicherer, sich als normaler Benutzer anzumelden und dann sudo zu verwenden, um administrative Aufgaben auszuführen.

Untersuchen wir die aktuelle Root-Login-Konfiguration und testen ihre Wirksamkeit.

Melden Sie sich zunächst per SSH als Benutzer labex an.

ssh labex@localhost

Sie sollten sich ohne Passwort anmelden, wenn Ihre SSH-Schlüsselkonfiguration aus den vorherigen Schritten korrekt ist.

Letzter Login: Mo 09. Jun 01:57:27 2025 von 47.251.66.143
[labex@host ~]$

Untersuchen wir nun die SSH-Serverkonfigurationsdatei, um die aktuellen Sicherheitseinstellungen zu verstehen:

sudo cat /etc/ssh/sshd_config | grep -E "^PermitRootLogin|^#PermitRootLogin"

Dieser Befehl zeigt Ihnen die aktuelle PermitRootLogin-Einstellung an. Sie sollten etwas Ähnliches sehen wie:

PermitRootLogin no

Diese Einstellung bedeutet, dass die direkte Anmeldung als Root über SSH deaktiviert ist, was eine bewährte Sicherheitsmethode darstellt.

Testen wir, ob die Anmeldung als Root tatsächlich blockiert ist. Beenden Sie zunächst die aktuelle SSH-Sitzung:

exit
exit
Verbindung zu localhost geschlossen.
[labex@host ~]$

Versuchen Sie nun, sich als root bei localhost anzumelden:

ssh root@localhost

Sie sollten eine Fehlermeldung "Permission denied" erhalten, was darauf hinweist, dass die direkte Anmeldung als Root nicht erlaubt ist (dies ist möglicherweise bereits in Ihrer Umgebung konfiguriert).

root@localhost's password:
Permission denied, please try again.
root@localhost's password:
Permission denied, please try again.
root@localhost's password:

Dies bestätigt, dass die Anmeldung als Root in dieser Umgebung deaktiviert ist, was die gewünschte Sicherheitskonfiguration darstellt. Die Fehlermeldung "Permission denied" zeigt, dass die Sicherheitsmaßnahme effektiv funktioniert.

Verständnis der Passwort-Authentifizierungssicherheit

Die Deaktivierung der Passwort-Authentifizierung zwingt Benutzer, auf sicherere Methoden wie die schlüsselbasierte SSH-Authentifizierung zurückzugreifen. Dies reduziert das Risiko von Brute-Force-Angriffen auf Ihren Server erheblich.

Untersuchen wir die aktuelle Einstellung für die Passwort-Authentifizierung und verstehen Sie, wie sie funktioniert.

Melden Sie sich per SSH als Benutzer labex an (mit Ihrem SSH-Schlüssel):

ssh labex@localhost
Letzter Login: Mo 09. Jun 01:57:32 2025 von 127.0.0.1
[labex@host ~]$

Überprüfen wir zunächst die aktuelle PasswordAuthentication-Einstellung:

sudo cat /etc/ssh/sshd_config | grep PasswordAuthentication
PasswordAuthentication no
## PasswordAuthentication.  Depending on your PAM configuration,
## PAM authentication, then enable this but set PasswordAuthentication

Wie Sie sehen, ist PasswordAuthentication no bereits konfiguriert, was bedeutet, dass die Passwort-Authentifizierung deaktiviert ist. Dies ist eine entscheidende Sicherheitseinstellung, die Brute-Force-Passwortangriffe verhindert.

Die Ausgabe zeigt:

  • PasswordAuthentication no - Dies ist die aktive Einstellung, die die Passwort-Authentifizierung deaktiviert.
  • Die kommentierten Zeilen geben zusätzlichen Kontext zur PAM-Konfiguration.

Diese Konfiguration bedeutet, dass Benutzer sich nur mit SSH-Schlüsseln, Zertifikaten oder anderen nicht-passwortbasierten Methoden authentifizieren können.

Beenden Sie die aktuelle SSH-Sitzung:

exit
exit
Verbindung zu localhost geschlossen.
[labex@host ~]$

Überprüfen wir nun, ob die schlüsselbasierte SSH-Authentifizierung korrekt funktioniert, während die Passwort-Authentifizierung deaktiviert ist:

ssh labex@localhost

Dies sollte ohne Passwort-Abfrage erfolgreich sein, indem Sie Ihren SSH-Schlüssel verwenden:

Letzter Login: Mo 09. Jun 02:00:22 2025 von 127.0.0.1
[labex@host ~]$

Dies demonstriert mehrere wichtige Sicherheitskonzepte:

  1. Die Passwort-Authentifizierung ist deaktiviert (PasswordAuthentication no) - Benutzer können sich nicht mit Passwörtern anmelden.
  2. Die SSH-Schlüssel-basierte Authentifizierung funktioniert korrekt - Sichere Authentifizierung ist weiterhin verfügbar.
  3. Der Server ist vor passwortbasierten Angriffen geschützt - Brute-Force-Angriffe sind wirkungslos.
  4. Die Anmeldung als Root ist deaktiviert - Administrativer Zugriff erfordert eine korrekte Benutzer-Eskalation.

Beenden Sie die Sitzung:

exit
exit
Verbindung zu localhost geschlossen.
[labex@host ~]$

Sie haben die OpenSSH-Server-Sicherheitskonfiguration erfolgreich untersucht und verstanden. Der Server demonstriert branchenübliche Sicherheitsmethoden mit deaktiviertem Root-Login und Passwort-Authentifizierung, während gleichzeitig ein sicherer Zugriff über die SSH-Schlüssel-basierte Authentifizierung gewährleistet ist.

Zusammenfassung

In diesem Labor haben die Teilnehmer gelernt, auf Systeme über SSH zuzugreifen, beginnend mit der Überprüfung der openssh-clients-Installation und der Verbindung zu localhost über SSH. Sie übten die Authentifizierung mit einem Passwort und verstanden die anfängliche Überprüfung der Hostauthentizität.

Das Labor führte die Benutzer weiter durch die Generierung und Verwendung von SSH-Schlüsselpaaren für die passwortlose Authentifizierung, die Verwaltung dieser Schlüssel mit ssh-agent und die Fehlerbehebung bei gängigen SSH-Verbindungsproblemen. Schließlich lernten die Teilnehmer, SSH-Client-Konfigurationen anzupassen und den OpenSSH-Server zu sichern, indem sie die Anmeldung als Root und die Passwort-Authentifizierung deaktivierten, und vertieften so ihr Verständnis für sichere Remote-Zugriffspraktiken.