SSH-Schluessel und Zertifikate sicher im Team teilen

„Schick mir den SSH-Key auf Slack." Ein alltaeglicher Satz in Entwicklungsteams. Der Serverzugang ist dringend, ein neues Teammitglied braucht die Einrichtung, das Deployment steht unmittelbar bevor.

Doch diese einfache Bitte kann der Beginn eines ernsthaften Sicherheitsvorfalls sein.

Warum SSH-Schluessel besonders gefaehrlich sind

SSH-Schluessel sind keine normalen Passwoerter. Sie gewaehren vollstaendigen Zugriff auf einen Server.

Faktor	Passwort	SSH-Schluessel
Geltungsbereich	Bestimmtes Konto	Gesamter Server
Auswirkung bei Leak	Dieses Konto	Alle Daten auf dem Server
Aenderungsaufwand	Sofort aenderbar	Schluessel neu generieren + alle Server aktualisieren
2FA	Verfuegbar	Schluessel ist die Authentifizierung

Gefaehrliche Methoden

1. Slack/Discord DM

Chat-Verlaeufe werden permanent gespeichert. Jeder kann nach „ssh" oder „key" suchen.

2. E-Mail

Permanent auf Mail-Servern archiviert, nach einmaligem Weiterleiten unkontrollierbar.

3. Gemeinsames Google Drive/Notion

Granulare Zugriffskontrolle schwierig. Lokale Kopien bleiben nach Synchronisation bestehen.

4. Git-Commit

Die gefaehrlichste Methode. Schluessel bleiben fuer immer im Git-Verlauf.

Sichere Methoden

Methode 1: LOCK.PUB Geheime Notiz (ideal fuer Einmal-Uebertragungen)

1. Geheime Notiz auf LOCK.PUB erstellen
2. SSH-Schluessel oder Zertifikat einfuegen
3. Starkes Passwort setzen
4. Kuerzestmoeglichen Ablauf setzen (1-4 Stunden)
5. Link per Slack, Passwort per Telefon uebermitteln
6. Nach lokaler Speicherung durch den Empfaenger laeuft der Link ab

Methode 2: Secrets Manager (fuer groessere Teams)

HashiCorp Vault, AWS Secrets Manager, Google Secret Manager.

Methode 3: SSH Certificate Authority (Langfristloesung)

Eine SSH-CA betreiben, die individuelle Zertifikate fuer jeden Nutzer ausstellt.

Methode 4: Individuelle Schluessel (am meisten empfohlen)

Grundsatz: Gemeinsamer Schluessel < Individuelle Schluessel
Gemeinsamer Schluessel geleakt → Gesamtes Team betroffen
Individueller Schluessel geleakt → Nur dieser Nutzer betroffen

Checkliste bei unvermeidlichem Teilen

Vor der Uebertragung

• Ist der Berechtigungsumfang minimal?
• Reicht ein Read-Only-Schluessel?
• Koennen IP-Beschraenkungen angewandt werden?

Waehrend der Uebertragung

• Werden Schluessel und Passwort ueber verschiedene Kanaele gesendet?
• Ist der Ablauf so kurz wie moeglich?

Nach der Uebertragung

• Bestaetigung der sicheren Speicherung durch den Empfaenger
• Verifizierung, dass der Link/die Notiz abgelaufen ist
• Ueberwachung der Nutzungsprotokolle

Rotationsplan fuer Schluessel

Schluesseltyp	Empfohlene Rotation
Produktionsserver-Schluessel	90 Tage
Deploy-Schluessel	90 Tage
SSL-Zertifikate	Bei jeder Erneuerung
API-Secrets	90 Tage
Entwicklungs-/Staging-Schluessel	180 Tage

Sicherheits-Checkliste fuer DevOps-Teams

• Werden fuer alle Server individuelle SSH-Schluessel verwendet?
• Haben gemeinsame Schluessel IP-Beschraenkungen?
• Werden Schluessel ausscheidender Mitarbeiter sofort deaktiviert?
• Gibt es einen Rotationsplan?
• Wurden SSH-Schluessel nie in ein Git-Repo committed?
• Gibt es keine Klartext-Schluessel in Chat-Verlaeufen?
• Wird ein Kanal mit Ablauf fuer Geheim-Uebertragungen genutzt?

Zusammenfassung

SSH-Schluessel und Zertifikate sind das Rueckgrat der Serversicherheit. Sie per Slack-DM oder E-Mail zu senden, ist wie den Haustürschluessel an ein oeffentliches Brett zu pinnen. Stellen Sie wenn moeglich individuelle Schluessel aus. Wenn Teilen unvermeidlich ist, nutzen Sie eine geheime Notiz mit kuerzestmoeglichem Ablauf.

Erstellen Sie jetzt eine geheime Notiz, um SSH-Schluessel sicher zu uebertragen.

Geheime Notiz erstellen