WardtermSSH-Client
DE
Herunterladen

SSH-Zugang teilen, ohne den privaten Schlüssel weiterzugeben

Lassen Sie sich von jeder Person ihren öffentlichen Schlüssel geben und tragen Sie ihn auf dem Server ein: im eigenen Konto der Person oder als eigene Zeile in ~/.ssh/authorized_keys des gemeinsamen Kontos. Ihr privater Schlüssel bleibt auf Ihrem Gerät, die Logs zeigen, wessen Schlüssel benutzt wurde, und eine Person zu entfernen heißt, eine Zeile zu löschen. Für befristeten Zugang setzen Sie expiry-time= vor die Zeile oder signieren ein kurzlebiges SSH-Zertifikat.

Soll jemand jetzt gleich in Ihrer Sitzung mitarbeiten? Mit Wardterm kommt die Person live dazu, ohne Konto auf dem Server. Zeigen

Aktualisiert am . Mit OpenSSH 10.0 unter Debian 13 in einem Wegwerf-Container ausgeführt: Konten pro Person mit install, ein gemeinsames Konto mit einer Zeile pro Person und expiry-time (eine abgelaufene Zeile wurde abgewiesen), ein mit -V +8h signiertes Benutzerzertifikat, über TrustedUserCAKeys akzeptiert, das Entfernen einer Zeile, usermod --expiredate und pkill.

Warum nicht einfach den Schlüssel teilen

Einem Kollegen den eigenen privaten Schlüssel zu schicken oder einen Deploy-Schlüssel für alle zu kopieren, funktioniert am ersten Tag und macht später Ärger:

  • Der Server sieht nur einen Schlüssel, seine Logs können also nicht sagen, wer was getan hat.
  • Wenn eine Person geht, lässt sie sich nur mit einem neuen Schlüssel für alle entfernen.
  • Jede Kopie auf einem Laptop, in einem Chatverlauf oder einem Backup ist eine weitere Stelle, an der er nach außen gelangen kann.

SSH ist für das Gegenteil gebaut: Jede Person hat ihr eigenes Schlüsselpaar, behält die private Hälfte und gibt nur die öffentliche heraus. Ein Server kann beliebig vielen öffentlichen Schlüsseln vertrauen.

Ein Konto pro Person

Am saubersten bekommt jede Person ihr eigenes Linux-Konto. Lassen Sie sich den öffentlichen Schlüssel geben, dann auf dem Server:

sudo adduser --disabled-password --gecos "" bob
sudo install -d -m 700 -o bob -g bob /home/bob/.ssh
sudo install -m 600 -o bob -g bob bob.pub /home/bob/.ssh/authorized_keys

Unter RHEL und ähnlichen Systemen nehmen Sie für die erste Zeile sudo useradd -m bob. Fügen Sie das Konto nur dann der Gruppe sudo oder wheel hinzu, wenn die Person root braucht, wie in Linux-Benutzer mit SSH und sudo anlegen beschrieben. Jeder Befehl ist dann einem Namen zugeordnet, und Dateien behalten ihren Eigentümer.

Mehrere Personen in einem gemeinsamen Konto

Manchmal müssen sich alle als derselbe Benutzer anmelden, etwa deploy oder der Standardbenutzer eines Cloud-Images. Dann bekommt jede Person eine eigene Zeile in der authorized_keys dieses Kontos, mit einem Kommentar, der sie benennt:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGk3... alice@laptop
expiry-time="20261231" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJq8... bob@laptop

Die Option expiry-time lässt Bobs Zeile nach diesem Datum nicht mehr funktionieren, ohne dass Sie daran denken müssen. Andere Optionen beschränken einen Schlüssel auf bestimmte Adressen oder einen Befehl, siehe einen SSH-Schlüssel einschränken. Da jede Person einen anderen Schlüssel hat, unterscheidet das Server-Log sie weiterhin am Fingerprint:

Accepted publickey for deploy from 203.0.113.25 port 51234 ssh2: ED25519 SHA256:vsze5ORPbYF/MMM4TTtuyy6yiEAYV1CcI4FOF0dV9wI

Listen Sie die Fingerprints in der Datei auf, um zu sehen, wem der Schlüssel gehört:

ssh-keygen -lf /home/deploy/.ssh/authorized_keys

Kurzlebiger Zugang mit Zertifikaten

Bei vielen Servern und häufigen Änderungen wird es mühsam, überall authorized_keys zu bearbeiten. Eine SSH-Zertifizierungsstelle löst das: Die Server vertrauen einmal der CA, und Sie signieren den öffentlichen Schlüssel jeder Person für eine festgelegte Zeit.

ssh-keygen -t ed25519 -f user_ca -C "team user CA"
ssh-keygen -s user_ca -I bob@example.com -n deploy -V +8h bob.pub

So entsteht bob-cert.pub, acht Stunden gültig für den Benutzer deploy. Kopieren Sie auf jedem Server user_ca.pub nach /etc/ssh/user_ca.pub und ergänzen Sie eine Zeile in der sshd_config:

TrustedUserCAKeys /etc/ssh/user_ca.pub

Bob legt bob-cert.pub neben seinen privaten Schlüssel und meldet sich wie gewohnt an. Läuft das Zertifikat ab, endet der Zugang, ohne dass ein Server angefasst wird. Bewahren Sie den CA-Schlüssel offline oder in einem eigenen System auf, denn er kann Zugang zu allem signieren. Die vollständige Einrichtung steht in SSH-Zertifikate erklärt.

Zugang wieder entziehen

Eine Schlüsselzeile löschen Sie einfach. Per Kommentar geht es schnell; für ein gründliches Aufräumen suchen Sie nach dem Fingerprint, wie in SSH-Schlüssel sperren, wenn jemand das Team verlässt gezeigt:

sudo sed -i.bak '/ bob@laptop$/d' /home/deploy/.ssh/authorized_keys

Ein persönliches Konto sperren Sie, sodass weder Schlüssel noch Passwort funktionieren, und beenden dann alles, was noch läuft:

sudo usermod --expiredate 1 bob
sudo pkill -KILL -u bob

Das Entfernen eines Schlüssels schließt bereits offene Sitzungen nicht, lassen Sie den zweiten Befehl also nicht weg. Ändern Sie danach alle Passwörter, Tokens und gemeinsamen Schlüssel, die die Person kannte.

Jemandem Ihr Terminal live zeigen

Manchmal geht es nicht um Zugang, sondern um Hilfe: Jemand soll Ihnen zusehen oder kurz selbst tippen. Auf einem Server, auf dem Sie beide ein Konto haben, kann tmux eine Sitzung teilen. Legen Sie dafür eine Gruppe an und starten Sie tmux auf einem Socket, den diese Gruppe erreicht:

sudo groupadd pair
sudo usermod -aG pair alice
sudo usermod -aG pair bob
tmux -S /tmp/pair new -s pair

Öffnen Sie in einem anderen Fenster den Socket für die Gruppe und lassen Sie Bob herein. Ab tmux 3.3 werden andere Benutzer abgewiesen, bis Sie das tun:

chgrp pair /tmp/pair
chmod 770 /tmp/pair
tmux -S /tmp/pair server-access -a bob
tmux -S /tmp/pair server-access -r bob

Die letzte Zeile macht Bob zum reinen Zuschauer; lassen Sie sie weg, darf er tippen. Er verbindet sich mit tmux -S /tmp/pair attach -t pair. Wenn Sie fertig sind, entfernt ihn tmux -S /tmp/pair server-access -d bob. Beide brauchen ein Konto auf diesem Server, und alles, was Bob tippt, läuft unter Ihrem Benutzer.

Gemeinsame Passwörter und andere Geheimnisse

Manches lässt sich nicht pro Person aufteilen: ein Netzwerkgerät mit einem einzigen Admin-Passwort, ein root-Passwort der Datenbank, ein Deploy-Schlüssel für ein Repository. Bewahren Sie so etwas in einem Passwortmanager oder Vault auf, den das Team gemeinsam nutzt, nicht im Chat oder auf einer Wiki-Seite, damit Sie wissen, wer es lesen kann. Wenn jemand geht, ändern Sie jedes Geheimnis, das die Person sehen konnte, denn das Entfernen aus dem Vault löscht nicht, was sie bereits kopiert hat.

Fragen

Können zwei Personen denselben privaten SSH-Schlüssel nutzen?

Technisch ja, aber dann kann der Server sie nicht unterscheiden, und einer Person den Zugang zu entziehen heißt, den Schlüssel für alle zu ersetzen. Geben Sie stattdessen jeder Person einen eigenen Schlüssel.

Ist es sicher, einen öffentlichen Schlüssel per E-Mail oder Chat zu schicken?

Ja. Ein öffentlicher Schlüssel ist zum Weitergeben da. Nur der private Schlüssel, die Datei ohne .pub, muss auf dem Gerät seines Besitzers bleiben.

Wie gebe ich jemandem nur für ein paar Tage Zugang?

Setzen Sie expiry-time="20261231" vor den Schlüssel in authorized_keys oder signieren Sie den Schlüssel mit ssh-keygen -s als Zertifikat mit einer Gültigkeit wie -V +3d. Beides läuft von selbst ab.

Kann ich jemanden mein Terminal sehen lassen, ohne ihm Zugang zu geben?

Ja. Mit tmux, einem gemeinsamen Socket und server-access -r kann die Person nur zuschauen. Zum Anhängen braucht sie trotzdem ein Konto auf demselben Server.

Quellen

Mehr zu Server absichern

Alle Anleitungen