SSH geschickt nutzen

Modul 2: SSH und Schlüssel · Lesezeit: 10 Minuten

Lernziel: Nach dieser Lektion können Sie SSH im Alltag bequem mit einer eigenen Konfigurationsdatei nutzen, Dateien mit scp und rsync kopieren und über einen Tunnel auf eine Datenbank zugreifen, ohne dass der Datenbankport zum Internet hin offen sein muss.

Kernbegriffe: ~/.ssh/config, Host, HostName, User, IdentityFile, scp, rsync, sftp, Port Forwarding, -L, Tunnel, ProxyJump, ServerAliveInterval, andere Portnummer, Schlüssel widerrufen

Weniger tippen mit ~/.ssh/config

Nach ein paar Wochen tippen Sie das Dutzende Male am Tag:

anna@laptop:~$ ssh -i ~/.ssh/id_ed25519 anna@192.0.2.10

Mit einer Konfigurationsdatei für den Client wird das kürzer, und Sie machen weniger Fehler. Die Datei liegt auf Ihrem eigenen Computer: ~/.ssh/config (Windows: C:\Users\anna\.ssh\config, ohne Dateiendung).

Host web1
    HostName 192.0.2.10
    User anna
    IdentityFile ~/.ssh/id_ed25519
    ServerAliveInterval 60

Host test
    HostName test.example.com
    User anna
    Port 2222

Jetzt genügt einfach:

anna@laptop:~$ ssh web1
anna@web1:~$

Was bewirken die Zeilen?

• Host ist der Spitzname, den Sie selbst wählen. Sie tippen ihn hinter ssh, scp und rsync.
• HostName ist die echte Adresse: eine IP-Adresse oder ein Name, der im DNS steht.
• User und Port sind der Benutzername und der Port, sodass Sie sich diese nicht mehr merken müssen.
• IdentityFile gibt den Schlüssel an. Praktisch, wenn Sie mehrere Schlüssel haben; ohne diese Zeile probiert ssh Ihre Standardschlüssel aus.
• ServerAliveInterval 60 sendet alle 60 Sekunden ein kleines Lebenszeichen. Viele Heimrouter und WLAN-Netze trennen eine stille Verbindung nach ein paar Minuten; damit bleibt Ihre Sitzung offen.

Auch hier gilt, wie beim Server, dass der erste Wert zählt. Setzen Sie allgemeine Regeln wie Host * daher ans Ende der Datei.

Dateien kopieren: scp, rsync und sftp

scp kopiert eine Datei, in derselben Form wie cp, aber mit host: davor:

anna@laptop:~$ scp backup.sql web1:/home/anna/
anna@laptop:~$ scp web1:/var/log/nginx/error.log .

rsync ist bei Ordnern und großen Datenmengen geschickter: Es überträgt nur, was sich geändert hat, und kann einen unterbrochenen Kopiervorgang fortsetzen. Es muss auf beiden Seiten installiert sein (apt install rsync).

anna@laptop:~$ rsync -avz --progress ./site/ web1:/var/www/example.com/

Achten Sie auf den Schrägstrich hinter ./site/: Mit Schrägstrich kopiert rsync den Inhalt des Ordners, ohne Schrägstrich den Ordner selbst (Sie erhalten dann /var/www/example.com/site/). Probieren Sie es im Zweifel zuerst mit --dry-run, und seien Sie sehr vorsichtig mit --delete, das auf der Empfängerseite alles löscht, was bei Ihnen nicht existiert.

sftp und grafische Programme wie FileZilla oder WinSCP nutzen dieselbe SSH-Verbindung und denselben Schlüssel. Ein separater FTP-Server ist also nicht nötig. Von einem altmodischen FTP-Server auf einem VPS ist abzuraten: Normales FTP überträgt Ihr Passwort unverschlüsselt über das Netzwerk.

Ein Tunnel statt eines offenen Ports

Das ist vielleicht das Nützlichste, was SSH kann. Angenommen, auf Ihrem Server läuft eine PostgreSQL-Datenbank. Sie möchten von Ihrem Laptop aus mit einem grafischen Programm darauf zugreifen. Die Versuchung ist groß, Port 5432 zum Internet hin zu öffnen. Tun Sie das nicht: Offene Datenbankports sind eine der häufigsten Ursachen für Datenpannen (Lektion 10.2), und der Kurs prüft später von außen, dass sie geschlossen sind (Aufgabe Z5.1).

Mit lokalem Port Forwarding lassen Sie SSH einen Tunnel aufbauen:

anna@laptop:~$ ssh -L 5432:127.0.0.1:5432 web1

Lesen Sie das so: "Lausche auf meinem Laptop auf Port 5432 und leite alles, was dort ankommt, durch die SSH-Verbindung an 127.0.0.1:5432 weiter, aus Sicht des Servers". Solange diese Sitzung offen ist, verbinden Sie Ihr Datenbankprogramm mit localhost Port 5432 auf Ihrem eigenen Laptop und landen bei der Datenbank auf dem Server.

Was macht das so gut?

• Die Datenbank lauscht auf dem Server nur auf 127.0.0.1 und ist von außen nicht erreichbar.
• Die Verbindung ist durch SSH verschlüsselt, auch wenn die Datenbank selbst keine Verschlüsselung hat.
• Nur wer sich per SSH anmelden kann, kommt heran. Sie nutzen also die starke Absicherung, die Sie bereits haben.

Läuft auf Ihrem Laptop bereits etwas auf 5432, wählen Sie links eine andere Nummer: -L 15432:127.0.0.1:5432, und verbinden Sie sich mit Port 15432. Tragen Sie den Tunnel in ~/.ssh/config ein, dann haben Sie ihn immer griffbereit:

Host web1-db
    HostName 192.0.2.10
    User anna
    LocalForward 15432 127.0.0.1:5432

Mit ssh -N web1-db erhalten Sie nur den Tunnel, ohne Kommandozeile.

Über einen Zwischenserver: ProxyJump

Manchmal erreichen Sie einen Server nur über einen anderen, zum Beispiel einen Datenbankserver ohne öffentliche IP-Adresse hinter Ihrem Webserver. ProxyJump springt über den ersten Server zum zweiten weiter:

Host db1
    HostName 10.0.0.5
    User anna
    ProxyJump web1

Der Unterschied zum Agent Forwarding (Lektion 2.1): Bei ProxyJump läuft die Verschlüsselung durchgehend zwischen Ihrem Laptop und db1. Der Zwischenserver reicht nur die Pakete weiter und kann Ihren Schlüssel nicht verwenden.

Eine andere Portnummer: ja oder nein?

Viele Anleitungen empfehlen, SSH auf einen anderen Port zu legen, zum Beispiel 2222. Was bewirkt das wirklich?

• Es verringert das Rauschen: Die meisten automatisierten Rateversuche probieren nur Port 22. Ihr Log wird ruhiger.
• Es ist keine Absicherung. Ein Scanner, der alle Ports abklappert, findet SSH innerhalb von Sekunden an seinem Versionsbanner.

Mit Schlüsseln und deaktiviertem Passwort-Login (Lektion 2.2) spielt der Port für die Sicherheit kaum eine Rolle. Möchten Sie trotzdem wechseln, dann in der richtigen Reihenfolge: neuen Port in der Firewall öffnen, SSH auf beiden Ports lauschen lassen, in einem zweiten Fenster testen, erst dann den alten Port schließen. Unter Ubuntu 24.04 und neuer gehören systemctl daemon-reload und systemctl restart ssh.socket dazu (Lektion 2.2). Denken Sie daran, dass Ihr Anbieter möglicherweise ebenfalls eine Firewall hat.

Zugang widerrufen

Ein ehemaliger Kollege oder ein Webentwickler hatte einen Schlüssel auf Ihrem Server und arbeitet nicht mehr für Sie? Den Zugang zu widerrufen ist einfach, wenn Sie den Überblick behalten:

1. Sehen Sie sich alle Schlüssel an: ssh-keygen -lf ~/.ssh/authorized_keys, und zwar für jeden Benutzer (auch /root/.ssh/authorized_keys).
2. Entfernen Sie die Zeile dieser Person.
3. Hatte er ein eigenes Benutzerkonto, sperren Sie es (Lektion 3.1) und prüfen Sie, ob er in der Gruppe sudo war (Lektion 3.2).
4. Hat er Passwörter gesehen, etwa ein Datenbankpasswort in einer Konfigurationsdatei, ersetzen Sie diese ebenfalls.

Ein gewöhnlicher Schlüssel hat kein Ablaufdatum. Was Sie nicht entfernen, funktioniert weiter, auch noch Jahre später. Geben Sie jemandem vorübergehend Zugang, können Sie vor seine Zeile in authorized_keys die Option expiry-time="20261231" setzen; nach diesem Datum lehnt der Server den Schlüssel ab.

Zusammenfassung

• ~/.ssh/config auf Ihrem eigenen Computer speichert pro Server Name, Benutzer, Port und Schlüssel; Host * gehört ans Ende.
• scp für einzelne Dateien, rsync für Ordner (achten Sie auf den Schrägstrich und auf --delete), sftp statt FTP.
• Mit ssh -L erreichen Sie eine Datenbank über einen verschlüsselten Tunnel, während der Datenbankport von außen geschlossen bleibt.
• ProxyJump springt sicher über einen Zwischenserver; besser als Agent Forwarding.
• Eine andere Portnummer verringert das Rauschen, sichert aber nicht ab. Schlüssel, die Sie nicht entfernen, funktionieren weiter.

Quiz

Aufgabe

Aufgabe O2.3: Eine SSH-Config und ein Tunnel. Legen Sie auf Ihrem eigenen Computer eine ~/.ssh/config mit einem Spitznamen für Ihren Server an, melden Sie sich nur mit ssh <bijnaam> an, kopieren Sie eine Datei mit scp oder rsync und bauen Sie mit -L einen Tunnel zu einem Dienst auf, der auf Ihrem Server nur auf 127.0.0.1 lauscht (haben Sie noch keine Datenbank, verwenden Sie Port 22 des Servers selbst: ssh -L 2200:127.0.0.1:22 <bijnaam> und danach ssh -p 2200 anna@localhost). Beantworten Sie die Fragen dazu, was der Tunnel bewirkt und warum der Port nicht geöffnet werden muss.

Weiterführende Informationen

Die Schritte in diesen Artikeln gelten für die VPS und Panels von WebOké; bei anderen Anbietern funktioniert es ähnlich.

• Per SSH auf Ihrem VPS anmelden (und einen SSH-Schlüssel erstellen)
• Handbuch ssh_config (Client-Einstellungen): https://man.openbsd.org/ssh_config
• Handbuch ssh (Optionen -L, -J, -N): https://man.openbsd.org/ssh