Einführung
In diesem Lab sammeln Sie praktische Erfahrungen bei der Konfiguration und Absicherung von SSH-Verbindungen, einer grundlegenden Fähigkeit für die Verwaltung von Linux-Systemen aus der Ferne. Sie beginnen damit, den Zugriff auf Remote-Systeme mittels SSH zu erlernen und verstehen dabei die Client-Server-Architektur sowie die grundlegenden Verbindungsbefehle. Dies umfasst die Überprüfung der SSH-Client-Installation, das Herstellen einer Verbindung zu einem Remote-Host, den Umgang mit Authentizitätsabfragen des Hosts sowie das An- und Abmelden an Remote-Systemen.
Auf dieser Grundlage vertiefen Sie Ihr Wissen mit fortgeschrittenen Themen wie der Generierung und Nutzung 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. Abschließend lernen Sie, SSH-Client-Konfigurationen für eine höhere Effizienz anzupassen und die Sicherheit Ihres OpenSSH-Servers durch die Deaktivierung von Root-Login und Passwort-Authentifizierung zu erhöhen, um einen robusten und sicheren Fernzugriff zu gewährleisten.
Zugriff auf Remote-Systeme mit SSH
In diesem Schritt lernen Sie, wie Sie mit SSH (Secure Shell) auf Remote-Systeme zugreifen. SSH ist ein kryptografisches Netzwerkprotokoll für den sicheren Betrieb von Netzwerkdiensten über ein unsicheres Netzwerk. Es stellt einen sicheren Kanal über eine Client-Server-Architektur bereit, indem es einen SSH-Client mit einem SSH-Server verbindet.
Hinweis: In dieser Lab-Umgebung sind einige Sicherheitsfunktionen, wie z. B. Einschränkungen für den Root-Login, aus Sicherheitsgründen möglicherweise bereits konfiguriert. Dies ist normal und demonstriert bewährte Verfahren in der Praxis.
Bevor Sie eine Verbindung zu Remote-Systemen herstellen, bereiten Sie Ihre Lab-Umgebung vor, indem Sie die OpenSSH-Client- und Server-Pakete installieren und den SSH-Dienst starten. SSH verwendet eine Client-Server-Architektur: Der Client (ssh) initiiert Verbindungen und der Server (sshd) nimmt sie entgegen. Sie installieren außerdem nano, das Sie später zum Bearbeiten der SSH-Konfigurationsdateien verwenden werden.
Führen Sie den folgenden Befehl aus, um die erforderlichen Pakete zu installieren. Das Flag -y bestätigt automatisch die Installationsaufforderungen:
sudo dnf install -y openssh-clients openssh-server nano
Starten Sie den SSH-Dienst und konfigurieren Sie ihn so, dass er beim Systemstart automatisch geladen wird:
sudo systemctl start sshd
sudo systemctl enable sshd
Überprüfen Sie, ob der SSH-Dienst läuft:
sudo systemctl status sshd
Sie sollten in der Ausgabe Active: active (running) sehen. Drücken Sie q, um die Statusansicht zu verlassen.
Zuerst verbinden Sie sich per 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 eine Verbindung zu localhost herzustellen.
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 lautet Ihr lokaler Benutzername labex.
Versuchen wir, uns mit Ihrem aktuellen Benutzernamen mit localhost zu verbinden:
ssh localhost
Wenn Sie sich zum ersten Mal verbinden, werden Sie von SSH aufgefordert, die Authentizität des Hosts zu bestätigen. Dies ist eine Sicherheitsmaßnahme, um Man-in-the-Middle-Angriffe zu verhindern. Geben Sie yes ein und drücken Sie Enter.
The authenticity of host 'localhost (127.0.0.1)' can't be established.
ED25519 key fingerprint is SHA256:h5k1mmPFylpxUCsKx+Mf8rN4wOrk9TmyRfzTvGWRm7A.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'localhost' (ED25519) to the list of known hosts.
labex@localhost's password:
Sie werden nach dem Passwort des Benutzers labex gefragt. Geben Sie labex ein und drücken Sie Enter.
labex@localhost's password:
Last login: Mon Jun 9 01:34:39 2025 from 47.251.66.143
[labex@host ~]$
Sie sind nun per SSH bei localhost angemeldet. Beachten Sie, dass Ihr Prompt 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
logout
Connection to localhost closed.
[labex@host ~]$
Versuchen wir nun, uns als root-Benutzer mit localhost zu verbinden. Beachten Sie, dass in dieser Umgebung der Root-Login aus Sicherheitsgründen standardmäßig deaktiviert sein kann.
ssh root@localhost
Sie werden nach dem Root-Passwort gefragt. Wenn der Root-Login jedoch deaktiviert ist, erhalten Sie möglicherweise die Meldung "Permission denied":
root@localhost's password:
Permission denied, please try again.
root@localhost's password:
Permission denied, please try again.
root@localhost's password:
Wenn der Root-Login deaktiviert ist, ist dies das erwartete Verhalten und demonstriert eine bewährte Sicherheitsmethode. Sie können Ctrl+C drücken, um den Verbindungsversuch abzubrechen.
SSH kann auch verwendet werden, um einen einzelnen Befehl auf einem Remote-System auszuführen, ohne eine interaktive Shell zu öffnen. Dies ist nützlich für schnelle Überprüfungen oder Automatisierungen.
Führen wir den Befehl hostname auf localhost als Benutzer labex aus:
ssh labex@localhost hostname
Sie werden nach dem Passwort des Benutzers labex gefragt. Geben Sie labex ein und drücken Sie Enter.
labex@localhost's password:
6846375f1c0e35fea6cb03e6
[labex@host ~]$
Der Befehl hostname wurde über SSH ausgeführt und seine Ausgabe wurde in Ihrem lokalen Terminal angezeigt. Sie wurden nicht in eine interaktive Shell weitergeleitet.
Lassen Sie uns abschließend untersuchen, wie SSH bekannte Hosts verwaltet. Wenn Sie eine Verbindung zu einem neuen SSH-Server herstellen, wird dessen Fingerabdruck des öffentlichen Schlüssels in Ihrer Datei ~/.ssh/known_hosts gespeichert. Diese Datei hilft Ihrem SSH-Client, die Identität des Servers bei zukünftigen Verbindungen zu überprüfen.
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 zur Kompatibilität. Sollte sich einer dieser Server-Schlüssel unerwartet ändern, warnt Sie SSH, was ein entscheidendes Sicherheitsmerkmal ist.
SSH-Schlüsselpaare für passwortlose Authentifizierung generieren und verwenden
In diesem Schritt lernen Sie, wie Sie SSH-Schlüsselpaare generieren und für die passwortlose Authentifizierung verwenden. Die SSH-Schlüssel-basierte Authentifizierung ist eine sicherere und bequemere Alternative zur Passwort-Authentifizierung. Anstatt bei jeder Verbindung ein Passwort einzugeben, 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 hinterlegt wird).
Zuerst müssen Sie ein SSH-Schlüsselpaar generieren. Hierfür 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 sowie 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:
Generating public/private rsa key pair.
Enter file in which to save the key (/home/labex/.ssh/id_rsa):
Drücken Sie Enter, um den Standard-Dateipfad (/home/labex/.ssh/id_rsa) zu akzeptieren.
Enter passphrase (empty for no passphrase):
Drücken Sie für dieses Lab zweimal Enter, um die Passphrase leer zu lassen. Während die Verwendung einer Passphrase in realen Szenarien empfohlen wird, um eine zusätzliche Sicherheitsebene hinzuzufügen, überspringen wir sie hier der Einfachheit halber, um die passwortlose Authentifizierung direkt zu demonstrieren.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/labex/.ssh/id_rsa
Your public key has been saved in /home/labex/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:QoV7pNBFu1kafGP3VJhpZuIdr1zc+qamJ1C2YAadgNY labex@6846375f1c0e35fea6cb03e6
The key's randomart image is:
+---[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/
total 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. Möglicherweise sehen Sie auch known_hosts.old, eine Sicherungskopie 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 genau dafür vorgesehen. Er fügt Ihren öffentlichen Schlüssel an die Datei ~/.ssh/authorized_keys an, wodurch Sie sich ohne Passwort anmelden können.
Führen Sie den Befehl ssh-copy-id aus und geben Sie Benutzer und Hostname an:
ssh-copy-id labex@localhost
Sie werden nach dem Passwort des Benutzers labex gefragt. Geben Sie labex ein und drücken Sie Enter.
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/labex/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
labex@localhost's password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'labex@localhost'"
and check to make sure that only the key(s) you wanted were added.
Die Befehlsausgabe bestätigt, dass ein Schlüssel hinzugefügt wurde. Versuchen Sie nun, sich als labex bei localhost anzumelden, ohne ein Passwort anzugeben:
ssh labex@localhost
Wenn alles korrekt konfiguriert ist, sollten Sie per SSH angemeldet werden, ohne nach einem Passwort gefragt zu werden.
Last login: Mon Jun 9 01:37:39 2025 from 47.251.66.143
[labex@host ~]$
Sie haben die passwortlose SSH-Authentifizierung mittels Schlüsselpaaren erfolgreich konfiguriert!
Um die Remote-Sitzung zu beenden, geben Sie exit ein:
exit
exit
Connection to localhost closed.
[labex@host ~]$
SSH-Schlüssel mit ssh-agent verwalten
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 der Agent übernimmt dann die Authentifizierung für die Dauer Ihrer Sitzung.
Obwohl Sie im vorherigen Schritt einen Schlüssel ohne Passphrase generiert haben, erstellen wir nun einen neuen Schlüssel mit einer Passphrase, um den Nutzen von ssh-agent zu demonstrieren.
Generieren Sie zuerst 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 Lab mypassphrase als Passphrase.
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): mypassphrase
Enter same passphrase again: mypassphrase
Your identification has been saved in /home/labex/.ssh/id_rsa_passphrase
Your public key has been saved in /home/labex/.ssh/id_rsa_passphrase.pub
The key fingerprint is:
SHA256:BuSxVlJb1lsiUFi2I5DAvyL01fJ5d480LT86dgtcHEg labex@6846375f1c0e35fea6cb03e6
The key's randomart image is:
+---[RSA 3072]----+
| ...=o+=*. E |
| .o.*.=..+ o |
| .=.o o. = . |
| . .+... .. . .|
| . . . +S. + |
| . o ..o . o * .|
| . . . . = * |
| oooo|
| ..+.o|
+----[SHA256]-----+
Hinweis: Wenn Sie versehentlich Enter drücken, ohne eine Passphrase einzugeben, wird der Schlüssel ohne eine solche erstellt. In diesem Fall können Sie die Dateien löschen und den Befehl erneut ausführen, wobei Sie sicherstellen müssen, dass Sie bei der Aufforderung mypassphrase eingeben.
Kopieren wir nun diesen neuen öffentlichen Schlüssel auf 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 Standard-Schlüssel eingerichtet haben, fragt der Befehl möglicherweise nicht nach einem Passwort und verwendet Ihre bestehende Authentifizierung:
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/labex/.ssh/id_rsa_passphrase.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'labex@localhost'"
and check to make sure that only the key(s) you wanted were added.
Versuchen Sie nun, sich mit diesem neuen Schlüssel bei localhost anzumelden. 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 dazu aufgefordert. Wenn Sie den Schlüssel jedoch versehentlich ohne Passphrase erstellt haben (wie im Beispiel-Output gezeigt), werden Sie direkt angemeldet:
Last login: Mon Jun 9 01:39:25 2025 from 47.251.66.143
[labex@host ~]$
Sie sind angemeldet. Beenden Sie nun die Sitzung:
exit
exit
Connection to localhost closed.
[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 zuerst den ssh-agent in Ihrer aktuellen Shell-Sitzung. Der Befehl eval wird verwendet, um die Umgebungsvariablen, die ssh-agent ausgibt, korrekt zu setzen.
eval "$(ssh-agent)"
Agent pid 1024
Die Ausgabe zeigt die Prozess-ID (PID) des ssh-agent.
Fügen Sie als Nächstes 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 dazu aufgefordert. Wenn nicht, wird der Schlüssel direkt hinzugefügt:
Identity added: /home/labex/.ssh/id_rsa_passphrase (labex@6846375f1c0e35fea6cb03e6)
Nachdem der Schlüssel nun zum ssh-agent hinzugefügt wurde, versuchen Sie erneut, sich mit demselben Schlüssel bei localhost anzumelden.
ssh -i ~/.ssh/id_rsa_passphrase labex@localhost
Sie sollten sich anmelden können, ohne nach einer Passphrase gefragt zu werden (egal ob Ihr Schlüssel eine hat oder nicht, da er jetzt vom Agenten verwaltet wird):
Last login: Mon Jun 9 01:39:49 2025 from 127.0.0.1
[labex@host ~]$
Sie haben ssh-agent erfolgreich zur Verwaltung Ihres SSH-Schlüssels verwendet.
Wichtiger Hinweis: Die Umgebungsvariablen von ssh-agent sind nur in der Shell-Sitzung verfügbar, in der Sie ihn gestartet haben. Wenn Sie sich in einer SSH-Sitzung befinden, müssen Sie diese beenden, um zu Ihrer lokalen Shell zurückzukehren und ssh-add-Befehle zu verwenden.
Beenden Sie zuerst die SSH-Sitzung:
exit
exit
Connection to localhost closed.
[labex@host ~]$
Um nun die aktuell in Ihrem ssh-agent geladenen Schlüssel zu sehen, können Sie ssh-add -l verwenden:
ssh-add -l
Wenn der Agent läuft und Schlüssel geladen sind, 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 aus dem ssh-agent zu entfernen, verwenden Sie ssh-add -D:
ssh-add -D
Wenn der Agent erreichbar ist, sehen Sie:
All identities removed.
Wenn Sie jedoch "Could not open a connection to your authentication agent" sehen, bedeutet dies, dass die Agent-Umgebung in Ihrer aktuellen Sitzung nicht verfügbar ist.
Wenn Sie nun versuchen, sich erneut anzumelden und Ihr Schlüssel eine Passphrase hat, werden Sie dazu aufgefordert, da der Schlüssel aus dem Agenten entfernt wurde:
ssh -i ~/.ssh/id_rsa_passphrase labex@localhost
Wenn Ihr Schlüssel eine Passphrase hat, sehen Sie:
Enter passphrase for key '/home/labex/.ssh/id_rsa_passphrase':
Wenn Ihr Schlüssel keine Passphrase hat, können Sie sich weiterhin direkt anmelden. Drücken Sie Ctrl+C, um den Verbindungsversuch abzubrechen, falls Sie nach einer Passphrase gefragt werden.
Um den ssh-agent-Prozess schließlich zu beenden, können Sie ssh-agent -k verwenden:
ssh-agent -k
Wenn die Umgebungsvariable SSH_AGENT_PID nicht gesetzt ist, sehen Sie möglicherweise:
SSH_AGENT_PID not set, cannot kill agent
Dies ist normal, wenn der Agent in einer anderen Shell-Sitzung gestartet wurde oder die Umgebungsvariablen nicht korrekt exportiert wurden.
SSH-Verbindungsprobleme beheben
In diesem Schritt lernen Sie, wie Sie häufige SSH-Verbindungsprobleme beheben. Wenn SSH-Verbindungen fehlschlagen, kann es schwierig sein, das genaue Problem zu lokalisieren. Der Befehl ssh bietet ausführliche Ausgabeoptionen (Verbose-Modus), die bei der Diagnose von Problemen helfen können, indem sie detaillierte Informationen über den Verbindungsprozess anzeigen.
Der Befehl ssh bietet drei Verbosity-Stufen: -v, -vv und -vvv. Jedes zusätzliche v erhöht die Menge der angezeigten Debugging-Informationen.
Beginnen wir mit dem Versuch, eine Verbindung zu einem nicht existierenden Port auf localhost herzustellen, um einen Verbindungsfehler zu demonstrieren und die Debugging-Ausgabe zu sehen.
Versuchen Sie zuerst mit -v (verbose), eine Verbindung zu Port 2222 herzustellen (der nicht laufen sollte):
ssh -v -p 2222 labex@localhost
Sie sehen eine Ausgabe ähnlich dieser, die darauf hinweist, dass die Verbindung verweigert 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 wir es nun mit -vv (ausführlicher):
ssh -vv -p 2222 labex@localhost
Die Ausgabe ist detaillierter und liefert 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
Versuchen Sie es schließlich mit -vvv (am ausführlichsten):
ssh -vvv -p 2222 labex@localhost
Diese Stufe bietet die maximale Menge an Debugging-Informationen, die zwar überwältigend sein kann, aber bei komplexen Problemen äußerst nützlich ist.
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 weist der Fehler Connection refused eindeutig darauf hin, dass auf Port 2222 kein SSH-Server läuft.
Simulieren wir nun ein häufiges Problem: einen geänderten Host-Schlüssel. Im ersten Schritt haben Sie eine Verbindung zu localhost hergestellt und dessen öffentlicher Schlüssel wurde in Ihrer Datei ~/.ssh/known_hosts gespeichert. Wenn sich der SSH-Server-Schlüssel ändern würde (z. B. aufgrund einer Server-Neuinstallation oder eines böswilligen Angriffs), würde Ihr SSH-Client diese Diskrepanz erkennen und die Verbindung verweigern.
Um dies zu simulieren, ändern wir absichtlich den known_hosts-Eintrag für localhost, um ihn ungültig zu machen.
Öffnen Sie zuerst die Datei ~/.ssh/known_hosts mit nano:
nano ~/.ssh/known_hosts
Sie sehen mehrere Zeilen mit verschiedenen Schlüsseltypen:
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=
Wählen Sie eine der Zeilen zum Ändern aus. Ändern wir für dieses Beispiel den ED25519-Schlüssel (die erste Zeile). Ändern Sie einige Zeichen in der langen Schlüsselzeichenfolge (z. B. ändern Sie das letzte Zeichen von G in A). Achten Sie darauf, nicht die gesamte Zeile oder andere Teile der Datei zu löschen.
Ändern Sie zum Beispiel:
...ZN6gG
in:
...ZN6gA
Speichern Sie die Datei, indem Sie Ctrl+X, dann Y zur Bestätigung und Enter zur Bestätigung 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:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:h5k1mmPFylpxUCsKx+Mf8rN4wOrk9TmyRfzTvGWRm7A.
Please contact your system administrator.
Add correct host key in /home/labex/.ssh/known_hosts to get rid of this message.
Offending key in /home/labex/.ssh/known_hosts:1
ED25519 host key for localhost has changed and you have requested strict checking.
Host key verification failed.
Dies ist eine kritische Sicherheitswarnung. Wenn Sie in einem realen Szenario darauf stoßen, 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.
Verwenden wir ssh-keygen -R, um den falschen Eintrag zu entfernen:
ssh-keygen -R localhost
## Host localhost found: line 1
## Host localhost found: line 2
## Host localhost found: line 3
/home/labex/.ssh/known_hosts updated.
Original contents retained as /home/labex/.ssh/known_hosts.old
Versuchen Sie nun erneut, eine Verbindung zu localhost herzustellen. Sie werden aufgefordert, die Authentizität des Hosts zu bestätigen, genau wie bei der allerersten Verbindung.
ssh labex@localhost
The authenticity of host 'localhost (127.0.0.1)' can't be established.
ED25519 key fingerprint is SHA256:h5k1mmPFylpxUCsKx+Mf8rN4wOrk9TmyRfzTvGWRm7A.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'localhost' (ED25519) to the list of known hosts.
Last login: Mon Jun 9 01:40:03 2025 from 127.0.0.1
[labex@host ~]$
Sie sind nun wieder erfolgreich über die schlüsselbasierte Authentifizierung verbunden.
Beenden Sie die Sitzung:
exit
exit
Connection to localhost closed.
[labex@host ~]$
SSH-Client-Konfigurationen anpassen
In diesem Schritt lernen Sie, wie Sie Ihre SSH-Client-Konfigurationen mithilfe der Datei ~/.ssh/config anpassen. Diese Datei ermöglicht es Ihnen, Aliase und spezifische Verbindungsparameter für verschiedene Remote-Hosts zu definieren, was Ihre SSH-Befehle vereinfacht und konsistenter macht.
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 fortgeschrittene Einstellungen wie Proxy-Befehle angeben.
Erstellen oder öffnen Sie zuerst die Datei ~/.ssh/config. Wenn sie nicht existiert, wird nano sie erstellen.
nano ~/.ssh/config
Fügen Sie die folgende Konfiguration zur Datei hinzu. 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 root-Benutzer. Sie gibt außerdem explizit die IdentityFile für den Benutzer labex an, um den in einem vorherigen Schritt generierten id_rsa-Schlüssel 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 Ctrl+X, dann Y zur Bestätigung und Enter zur Bestätigung des Dateinamens drücken.
Versuchen wir nun, uns mit diesen neuen Aliasen mit localhost zu verbinden.
Verbinden Sie sich als labex unter Verwendung des Alias localhost_labex:
ssh localhost_labex
Da Sie IdentityFile ~/.ssh/id_rsa konfiguriert haben und id_rsa keine Passphrase hat, sollten Sie ohne Passwortabfrage angemeldet werden.
Last login: Mon Jun 9 01:54:16 2025 from 47.251.66.143
[labex@host ~]$
Beenden Sie die Sitzung:
exit
exit
Connection to localhost closed.
[labex@host ~]$
Verbinden Sie sich nun als root unter Verwendung des Alias localhost_root:
ssh localhost_root
Sie werden nach dem Passwort des root-Benutzers gefragt. Da der Root-Login in dieser Umgebung jedoch deaktiviert ist, erhalten Sie die Meldung "Permission denied":
root@localhost's password:
Permission denied, please try again.
root@localhost's password:
Drücken Sie Ctrl+C, um den Verbindungsversuch abzubrechen:
^C
Dies demonstriert, dass der SSH-Konfigurationsalias funktioniert, die Verbindung jedoch aufgrund der Sicherheitsrichtlinie, die den Root-Login deaktiviert, fehlschlägt.
Wie Sie sehen, vereinfacht die Datei ~/.ssh/config Ihre SSH-Befehle durch die Vorkonfiguration gängiger Verbindungsparameter.
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, sich mit dem Alias localhost_port_example zu verbinden:
ssh localhost_port_example
Diese Verbindung wird fehlschlagen, da localhost nicht auf Port 2222 hört, aber es zeigt, wie Sie einen benutzerdefinierten Port in Ihrer SSH-Konfiguration angeben.
ssh: connect to host localhost port 2222: Cannot assign requested address
You can find some explanations for typical errors at this link:
https://red.ht/support_rhel_ssh
Sie können Ihre aktuelle SSH-Konfiguration anzeigen, um alle definierten Hosts zu sehen:
cat ~/.ssh/config
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
Bereinigen wir abschließend 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 nun so aussehen:
Host localhost_labex
HostName localhost
User labex
IdentityFile ~/.ssh/id_rsa
Host localhost_root
HostName localhost
User root
Speichern Sie die Datei.
OpenSSH-Server-Sicherheitskonfiguration verstehen
In diesem Schritt lernen Sie bewährte Sicherheitsmethoden für OpenSSH-Server kennen, indem Sie die aktuelle Sicherheitskonfiguration untersuchen. Sie werden verstehen, wie Einschränkungen für den Root-Login und Einstellungen zur Passwort-Authentifizierung funktionieren, um Ihren Server vor unbefugtem Zugriff zu schützen.
Hinweis: In dieser Lab-Umgebung untersuchen Sie die aktuelle SSH-Sicherheitskonfiguration und verstehen verschiedene Sicherheitseinstellungen. Dieser Schritt konzentriert sich darauf, diese Sicherheitsmaßnahmen zu verstehen und bewährte Verfahren für die Konfiguration von SSH-Servern zu erlernen.
Sicherheit des Root-Logins verstehen
Das Erlauben eines direkten Root-Logins per SSH wird im Allgemeinen nicht empfohlen, da das Root-Konto über volle administrative Privilegien 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 Konfiguration für den Root-Login und testen wir deren Wirksamkeit.
Melden Sie sich zuerst per SSH als Benutzer labex an.
ssh labex@localhost
Sie sollten sich ohne Passwort anmelden können, wenn Ihre SSH-Schlüssel-Einrichtung aus den vorherigen Schritten korrekt ist.
Last login: Mon Jun 9 01:57:27 2025 from 47.251.66.143
[labex@host ~]$
Untersuchen wir nun die SSH-Server-Konfigurationsdatei, um die aktuellen Sicherheitseinstellungen zu verstehen:
sudo cat /etc/ssh/sshd_config | grep -E "^PermitRootLogin|^#PermitRootLogin"
Dieser Befehl zeigt Ihnen die aktuelle Einstellung für PermitRootLogin. Sie sollten etwas sehen wie:
PermitRootLogin no
Diese Einstellung bedeutet, dass der direkte Root-Login per SSH deaktiviert ist, was eine bewährte Sicherheitsmethode darstellt.
Testen wir, ob der Root-Login tatsächlich blockiert ist. Beenden Sie zuerst die aktuelle SSH-Sitzung:
exit
exit
Connection to localhost closed.
[labex@host ~]$
Versuchen Sie nun, sich als root bei localhost anzumelden:
ssh root@localhost
Sie sollten eine Meldung "Permission denied" sehen, die darauf hinweist, dass der direkte Root-Login 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 der Root-Login in dieser Umgebung deaktiviert ist, was die gewünschte Sicherheitskonfiguration darstellt. Die Meldung "Permission denied" zeigt, dass die Sicherheitsmaßnahme effektiv funktioniert.
Sicherheit der Passwort-Authentifizierung verstehen
Die Deaktivierung der Passwort-Authentifizierung zwingt Benutzer dazu, sich auf sicherere Methoden wie die SSH-Schlüssel-basierte Authentifizierung zu verlassen. Dies reduziert das Risiko von Brute-Force-Angriffen auf Ihren Server erheblich.
Untersuchen wir die aktuelle Einstellung für die Passwort-Authentifizierung und verstehen wir, wie sie funktioniert.
Melden Sie sich per SSH als Benutzer labex an (unter Verwendung Ihres SSH-Schlüssels):
ssh labex@localhost
Last login: Mon Jun 9 01:57:32 2025 from 127.0.0.1
[labex@host ~]$
Überprüfen wir zuerst die aktuelle Einstellung für PasswordAuthentication:
sudo cat /etc/ssh/sshd_config | grep PasswordAuthentication
PasswordAuthentication yes
## PasswordAuthentication. Depending on your PAM configuration,
## PAM authentication, then enable this but set PasswordAuthentication
Wie Sie sehen, ist PasswordAuthentication yes aktuell konfiguriert, was bedeutet, dass die Passwort-Authentifizierung aktiviert ist. Während dies Benutzern die Authentifizierung mit Passwörtern ermöglicht, stellt es auch ein Sicherheitsrisiko dar, da der Server anfällig für Brute-Force-Passwortangriffe ist.
Die Ausgabe zeigt:
PasswordAuthentication yes- Dies ist die aktive Einstellung, die die Passwort-Authentifizierung aktiviert- Die auskommentierten Zeilen bieten zusätzlichen Kontext zur PAM-Konfiguration
Diese Konfiguration bedeutet, dass sich Benutzer sowohl mit Passwörtern als auch mit SSH-Schlüsseln authentifizieren können. Für eine erhöhte Sicherheit wird empfohlen, die Passwort-Authentifizierung zu deaktivieren und sich ausschließlich auf die SSH-Schlüssel-basierte Authentifizierung zu verlassen.
Beenden Sie die aktuelle SSH-Sitzung:
exit
exit
Connection to localhost closed.
[labex@host ~]$
Überprüfen wir nun, ob die SSH-Schlüssel-basierte Authentifizierung ordnungsgemäß funktioniert, während die Passwort-Authentifizierung deaktiviert ist:
ssh labex@localhost
Dies sollte ohne Passwortabfrage erfolgreich sein, unter Verwendung Ihres SSH-Schlüssels:
Last login: Mon Jun 9 02:00:22 2025 from 127.0.0.1
[labex@host ~]$
Dies demonstriert mehrere wichtige Sicherheitskonzepte:
- Passwort-Authentifizierung ist aktiviert (
PasswordAuthentication yes) - Benutzer können sich sowohl mit Passwörtern als auch mit SSH-Schlüsseln anmelden - SSH-Schlüssel-basierte Authentifizierung funktioniert ordnungsgemäß - Eine sicherere Authentifizierungsmethode ist verfügbar
- Der Server erlaubt beide Authentifizierungsmethoden - Obwohl dies bequem ist, kann es Sicherheitsrisiken durch Brute-Force-Angriffe bergen
- Root-Login ist deaktiviert - Der administrative Zugriff erfordert eine ordnungsgemäße Benutzer-Eskalation
Sicherheitsempfehlung: Erwägen Sie für Produktionsumgebungen, PasswordAuthentication no zu setzen, um die Sicherheit zu erhöhen, indem Benutzer gezwungen werden, ausschließlich die SSH-Schlüssel-basierte Authentifizierung zu verwenden.
Beenden Sie die Sitzung:
exit
exit
Connection to localhost closed.
[labex@host ~]$
Sie haben die OpenSSH-Server-Sicherheitskonfiguration erfolgreich untersucht und verstanden. Der Server hat derzeit den Root-Login deaktiviert (was bewährten Sicherheitsmethoden entspricht) und die Passwort-Authentifizierung aktiviert (was Flexibilität bietet, aber für Produktionsumgebungen zusätzliche Sicherheitsüberlegungen erfordern kann). Sie haben außerdem überprüft, dass die SSH-Schlüssel-basierte Authentifizierung als sicherere Authentifizierungsmethode ordnungsgemäß funktioniert.
Zusammenfassung
In diesem Lab lernten die Teilnehmer, wie man mit SSH auf Systeme zugreift, beginnend mit der Überprüfung der openssh-clients-Installation und der Verbindung zu localhost per SSH. Sie übten die Authentifizierung mit einem Passwort und verstanden die anfängliche Überprüfung der Host-Authentizität.
Das Lab führte die Benutzer weiter durch die Generierung und Nutzung von SSH-Schlüsselpaaren für die passwortlose Authentifizierung, die Verwaltung dieser Schlüssel mit ssh-agent und die Fehlerbehebung bei häufigen SSH-Verbindungsproblemen. Abschließend lernten die Teilnehmer, SSH-Client-Konfigurationen anzupassen und den OpenSSH-Server durch die Deaktivierung von Root-Login und Passwort-Authentifizierung abzusichern, wodurch ihr Verständnis für sichere Fernzugriffspraktiken verbessert wurde.
