In modernen Deployment-Workflows, insbesondere wenn du automatisierte Prozesse wie GitHub Actions nutzt, spielt der private SSH-Schlüssel eine zentrale Rolle. Dabei ist es wichtig zu wissen: Der private Schlüssel darf niemals öffentlich zugänglich gemacht oder in ein Repository eingecheckt werden. Stattdessen solltest du ihn in einer sicheren, verschlüsselten Umgebung hinterlegen, sodass er nur während des Deployment-Prozesses verwendet werden kann. In diesem Artikel zeige ich dir, wie du dies umsetzt.

1. Warum ist der private SSH-Schlüssel so wichtig?

Der private Schlüssel ist der geheime Teil des Schlüsselpaares, das du zur Authentifizierung beim Zugriff auf entfernte Server oder Git-Repositories verwendest. Während GitHub ausschließlich den öffentlichen Schlüssel benötigt (z. B. als Deploy Key in einem Repository), muss der private Schlüssel sicher bleiben – wird er kompromittiert, kann sich ein Angreifer als dein Deployment-User ausgeben.

Wichtige Punkte:

• Nur für dich sichtbar: Der private Schlüssel sollte niemals an Dritte oder in öffentliche Bereiche gelangen.
• Integrität bewahren: Selbst bei automatisierten Prozessen (z. B. in CI/CD-Pipelines) darf der private Schlüssel nur in isolierten, verschlüsselten Umgebungen gespeichert werden.
• Ausfallsicherheit: Bei Verlust oder Kompromittierung des privaten Schlüssels muss er unverzüglich ersetzt werden.

2. Wo den privaten SSH-Schlüssel sicher hinterlegen?

a) Lokal auf deinem Deployment-Server

Wenn du einen dedizierten Deploy-User wie sshdeploy auf deinem Server eingerichtet hast, bleibt der private Schlüssel im Home-Verzeichnis unter ~/.ssh/ (z. B. ~/.ssh/id_ed25519). Hier solltest du die Dateiberechtigungen strikt einschränken:

chmod 600 ~/.ssh/id_ed25519

So stellst du sicher, dass nur der Benutzer selbst den Schlüssel lesen kann.

b) In GitHub Actions: Nutzung von Secrets

Für automatisierte Deployments mit GitHub Actions ist es gängige Praxis, den privaten SSH-Schlüssel als Secret im Repository zu hinterlegen. GitHub verschlüsselt diese Secrets und stellt sie in den Actions-Workflows als Umgebungsvariablen zur Verfügung.

So funktioniert’s:

Secret anlegen:
Gehe in dein Repository, wähle den Reiter Settings > Secrets and variables > Actions, und klicke auf New repository secret.
Vergib einen eindeutigen Namen, z. B. SSH_PRIVATE_KEY, und füge den Inhalt deines privaten Schlüssels ein.

In GitHub Actions verwenden:
In deinem Workflow liest du das Secret aus und schreibst den Schlüssel in eine Datei, die du dann für die SSH-Verbindung nutzt.
Beispiel:

name: Deploy

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v3

      - name: Set up SSH key
        run: |
          mkdir -p ~/.ssh
          echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/id_ed25519
          chmod 600 ~/.ssh/id_ed25519
      # Füge hier weitere Deployment-Schritte hinzu, die über SSH authentifizieren

Dieser Ansatz stellt sicher, dass der private Schlüssel nur zur Laufzeit der Action im Runner verfügbar ist – permanent sichtbar ist er dadurch nicht.

c) Andere Secret-Management-Lösungen

Neben GitHub Actions Secrets kannst du auch externe Secret-Management-Systeme wie HashiCorp Vault, AWS Secrets Manager oder Azure Key Vault verwenden. Diese Systeme bieten oft zusätzliche Funktionen zur Rotation und zum Audit der Zugriffsmuster.

3. Best Practices zum Umgang mit dem privaten SSH-Schlüssel

• Nie in Repositories einchecken:
  Selbst wenn das Repository privat ist, sollte der private SSH-Schlüssel niemals ins Quellcode-Management gelangen.
• Regelmäßige Rotation:
  Stelle sicher, dass du den SSH-Schlüssel in regelmäßigen Abständen erneuerst. Ein regelmäßiger Wechsel minimiert das Risiko eines langfristigen Missbrauchs.
• Zugriff beschränken:
  Auf dem Deployment-Server sollte der Benutzer sshdeploy nur über die minimal nötigen Rechte verfügen. Für CI/CD-Pipelines gilt: Gib dem Prozess nur Zugriff auf jene Ressourcen, die er wirklich benötigt.
• Überwachung:
  Überwache Zugriffe und Log-Dateien sowohl auf dem Deployment-Server als auch in deinen CI/CD-Umgebungen, um unautorisierte Zugriffe frühzeitig zu identifizieren.

4. Fazit

Der private SSH-Schlüssel ist ein zentrales Element in der sicheren Kommunikation bei GitHub-Deployments. Indem du ihn niemals öffentlich machst, sondern in sicheren Umgebungen – wie einem abgeschlossenen Benutzerverzeichnis oder als verschlüsseltes Secret in GitHub Actions – hinterlegst, erhöhst du die Sicherheit deines Deployment-Workflows signifikant.

Durch die konsequente Anwendung der Best Practices und den gezielten Einsatz moderner Secret-Management-Lösungen stellst du sicher, dass dein automatisierter Deployment-Prozess auch in Zukunft robust und vor unautorisierten Zugriffen geschützt bleibt.