Lab-Lektion · kostenlos

SSH erklärt – verstehen und im Terminal üben

SSH ist die sichere Tür zu jedem Server. Wer sie versteht, arbeitet sicher und bequem zugleich. Hier lernst du, wie Schlüssel statt Passwörter funktionieren – und übst den Login auf einer echten VM.

Schlüsselpaar statt Passwort

Ein SSH-Schlüsselpaar besteht aus einem privaten (bleibt bei dir) und einem öffentlichen Schlüssel (kommt auf den Server). Mit ssh-keygen erzeugst du es. Der Login ohne Passwort ist nicht nur bequemer, sondern auch sicherer gegen Brute-Force.

Verbinden und known_hosts

Mit ssh user@host verbindest du dich. Beim ersten Mal bestätigst du den Fingerprint – er landet in known_hosts und schützt vor Man-in-the-Middle-Angriffen.

Den SSH-Server härten

Passwort-Login deaktivieren, Root-Login verbieten, Port ändern: kleine Änderungen in der sshd_config mit großer Wirkung. Genau das vertiefst du im Server-Hardening.

Was der Fingerabdruck beim ersten Verbinden bedeutet

Beim ersten Verbinden zeigt SSH einen Fingerabdruck und fragt, ob du ihn akzeptierst. Diese Frage ist der einzige Moment, in dem ein Angreifer sich dazwischenschieben könnte – danach merkt sich ~/.ssh/known_hosts den Schlüssel und warnt bei jeder Abweichung. Blind mit „yes“ zu bestätigen ist verbreitet und trotzdem die schwächste Stelle des ganzen Verfahrens.

Warum der private Schlüssel nie das Gerät verlässt

Der private Schlüssel wird beim Anmelden nicht übertragen. Der Server schickt eine Aufgabe, dein Rechner löst sie mit dem privaten Schlüssel, und nur die Antwort geht zurück. Deshalb ist ein Schlüssel einem Passwort überlegen: Ein mitgelesener Anmeldevorgang gibt einem Angreifer nichts in die Hand, was sich wiederverwenden ließe.

Der SSH-Agent: Passphrase einmal statt jedes Mal

Ein Schlüssel ohne Passphrase ist eine Datei, die allein zum Zugang genügt – wer sie kopiert, ist drin. Mit Passphrase müsstest du sie bei jeder Verbindung tippen. Der ssh-agent löst das: Er hält den entschlüsselten Schlüssel für die Dauer der Sitzung im Speicher. Einmal ssh-add, danach verbindest du dich ohne Eingabe, und beim Abmelden ist der Schlüssel wieder geschützt.

Konfiguration statt langer Befehle

In ~/.ssh/config hinterlegst du je Ziel einen Namen, den Benutzer, den Port und den Schlüssel. Aus ssh -i ~/.ssh/lab -p 2222 benutzer@10.0.20.20 wird ssh lab. Das spart nicht nur Tippen: Wer die Verbindungsdaten an einer Stelle pflegt, macht bei einem Wechsel des Ports auch nur an einer Stelle einen Fehler.

Was oft schiefgeht

Der teuerste Fehler ist, sich auszusperren: Passwort-Anmeldung abschalten, bevor die Schlüssel-Anmeldung nachweislich funktioniert. Deshalb gilt die Regel, eine zweite Sitzung offen zu lassen, bis die neue Konfiguration geprüft ist. Zweiter Klassiker: den privaten Schlüssel auf den Server kopieren statt den öffentlichen – damit liegt das Geheimnis genau dort, wo es nicht hingehört. Dritter: den Port ändern und die Firewall-Regel vergessen.

Portweiterleitung: durch den Tunnel arbeiten

SSH transportiert nicht nur eine Sitzung, sondern auf Wunsch auch Netzverbindungen. Mit ssh -L 8080:localhost:80 lab erreichst du einen Webdienst, der auf dem Zielrechner nur lokal lauscht, über http://localhost:8080 auf deinem eigenen Gerät. Das ist der saubere Weg, eine Verwaltungsoberfläche zu benutzen, ohne sie ins Internet zu stellen – und der Grund, warum ein Dienst, der an 127.0.0.1 gebunden ist, trotzdem bequem bedienbar bleibt. Die Verbindung endet mit der SSH-Sitzung, es bleibt kein offener Port zurück.

Befehle zum Ausprobieren

Schlüsselpaar erzeugen und übertragen

$ ssh-keygen -t ed25519 -C "lab-uebung"$ ssh-copy-id benutzer@zielhost$ ssh benutzer@zielhost

ed25519 statt RSA: kürzer, schneller und heute der Standard. ssh-copy-id hängt den öffentlichen Schlüssel an ~/.ssh/authorized_keys auf dem Ziel an, ohne die Datei zu überschreiben.

Verbindung prüfen, bevor du die Konfiguration änderst

$ ssh -v benutzer@zielhost$ sudo sshd -t$ sudo systemctl reload ssh

sshd -t prüft die Konfigurationsdatei auf Syntaxfehler. Erst danach neu laden – ein restart mit kaputter Datei sperrt dich aus, wenn du keine zweite offene Sitzung hast.

Rechte im .ssh-Verzeichnis geraderücken

$ chmod 700 ~/.ssh$ chmod 600 ~/.ssh/authorized_keys$ ls -ld ~/.ssh

SSH ignoriert Schlüssel, wenn die Rechte zu weit sind – und sagt das nur im ausführlichen Modus. Zu weite Rechte sind die häufigste Ursache dafür, dass ein korrekter Schlüssel nicht angenommen wird.

Agent nutzen und Verbindung benennen

$ eval "$(ssh-agent -s)"$ ssh-add ~/.ssh/id_ed25519$ printf 'Host lab\n  HostName 10.0.20.20\n  User lerner\n' >> ~/.ssh/config$ ssh lab

Nach dem Eintrag in ~/.ssh/config genuegt der Kurzname. Die Datei darf nur dir gehoeren – chmod 600 ~/.ssh/config, sonst ignoriert SSH sie.

Häufige Fehlermeldungen

Permission denied (publickey).: Ursache: Der Server akzeptiert nur Schlüssel, und deiner passt nicht: falscher Benutzer, Schlüssel nicht in authorized_keys, oder die Rechte im .ssh-Verzeichnis sind zu weit.; Lösung: Mit ssh -v mitlesen, welcher Schlüssel angeboten wird, und auf dem Ziel chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys setzen.
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!: Ursache: Der Schlüssel des Servers weicht von dem in known_hosts ab. Harmlos nach einer Neuinstallation – aber genau so sieht auch ein Angriff aus.; Lösung: Erst klären, warum sich der Schlüssel geändert hat. Wenn die Neuinstallation bekannt ist: ssh-keygen -R zielhost und beim nächsten Verbinden den neuen Fingerabdruck prüfen.
ssh: connect to host zielhost port 22: Connection refused: Ursache: Auf dem Port hört nichts – der Dienst läuft nicht, oder er wurde auf einen anderen Port gelegt.; Lösung: Auf dem Ziel sudo systemctl status ssh prüfen und den Port mit sudo ss -tlnp | grep sshd nachsehen. Bei „Connection timed out“ statt „refused“ liegt es dagegen an der Firewall.
Bad owner or permissions on /home/lerner/.ssh/config: Ursache: Die Konfigurationsdatei ist fuer andere lesbar oder gehoert einem anderen Benutzer. SSH verweigert sie dann vollstaendig.; Lösung: chmod 600 ~/.ssh/config und chown $USER ~/.ssh/config.
sign_and_send_pubkey: signing failed: agent refused operation: Ursache: Der Agent hat den Schluessel nicht mehr – etwa nach einem Neustart oder weil die Sitzung eine andere ist als die, in der ssh-add lief.; Lösung: Mit ssh-add -l nachsehen, welche Schluessel geladen sind, und ihn mit ssh-add erneut hinzufuegen.

In fünf Schritten

01Mit ssh-keygen -t ed25519 ein Schlüsselpaar erzeugen und eine Passphrase vergeben.
02Den öffentlichen Schlüssel mit ssh-copy-id auf das Ziel bringen – nie den privaten kopieren.
03Anmeldung mit Schlüssel testen, solange die Passwort-Anmeldung noch aktiv ist.
04Erst dann in /etc/ssh/sshd_config PasswordAuthentication no und PermitRootLogin no setzen.
05Mit sudo sshd -t prüfen, neu laden – und eine ZWEITE Sitzung offen lassen, bis die neue funktioniert.

Was du übst

ssh-keygen, Schlüsselpaaressh user@host, known_hostssshd_config härtenknown_hosts & Fingerabdruck

Jetzt im Lab üben →

Weiterlernen

Kontakt aufnehmen

Haben Sie ein Projekt?

Lassen Sie uns gemeinsam Ihre Idee in die Tat umsetzen. Wir beraten Sie gerne unverbindlich.

Kontakt aufnehmen →