SSH-Schlüssel: Erstellung, Multi-Account und…

SSH-Schlüssel: Sicherere Authentifizierung als Passwörter

Vergleich	Passwort	SSH-Schlüssel
Authentifizierungsmethode	Wissensfaktor (was du weißt)	Besitzfaktor (was du hast)
Brute-Force	Möglich	Praktisch unmöglich
Phishing-Risiko	Hoch	Niedrig (Privatschlüssel verlässt nie den lokalen Rechner)
Server-Leck	Klartext/Hash anfällig für Rainbow-Tables	Nur öffentlicher Schlüssel gespeichert, Privatschlüssel nicht ableitbar
Komfort	Jedes Mal eingeben	Einmal konfiguriert, automatische Authentifizierung

1. Schlüsselpaar erstellen

Ed25519 (empfohlen)

ssh-keygen -t ed25519 -C "your@email.com"

Parameter	Beschreibung
`-t ed25519`	Algorithmus-Typ (Ed25519, am sichersten und schnellsten)
`-C`	Kommentar (meist E-Mail zur Identifikation)

RSA (Kompatibilitätsalternative)

ssh-keygen -t rsa -b 4096 -C "your@email.com"

Algorithmus	Schlüssellänge	Sicherheit	Leistung	Empfehlung
Ed25519	256 bit	Höchste	Am schnellsten	✅
ECDSA P256	256 bit	Hoch	Schnell	Optional
RSA 4096	4096 bit	Hoch	Langsam	Kompatibilitätsalternative
RSA 2048	2048 bit	Mittel	Langsam	❌ Nicht empfohlen

Erstellungsprozess

$ ssh-keygen -t ed25519 -C "dev@example.com"
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/user/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase): ****
Enter same passphrase again: ****
Your identification has been saved in /home/user/.ssh/id_ed25519
Your public key has been saved in /home/user/.ssh/id_ed25519.pub

Es wird dringend empfohlen, eine Passphrase zu setzen: Selbst wenn der Privatschlüssel geleakt wird, verhindert eine Passphrase die direkte Nutzung.

2. Öffentlichen Schlüssel bereitstellen

GitHub / GitLab

# Öffentlichen Schlüssel kopieren
cat ~/.ssh/id_ed25519.pub | clip

# GitHub → Settings → SSH and GPG keys → New SSH key
# Inhalt des öffentlichen Schlüssels einfügen

Server

# Methode 1: ssh-copy-id
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server.com

# Methode 2: Manuell anhängen
cat ~/.ssh/id_ed25519.pub | ssh user@server.com 'mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys'

Verbindung überprüfen

ssh -T git@github.com
# Hi username! You've successfully authenticated...

ssh user@server.com
# Direkte Anmeldung ohne Passwort

3. Multi-Account-Konfiguration

Szenario: Arbeits-GitHub + persönlicher GitHub

# Zwei Schlüsselpaare erstellen
ssh-keygen -t ed25519 -C "work@company.com" -f ~/.ssh/id_work
ssh-keygen -t ed25519 -C "personal@gmail.com" -f ~/.ssh/id_personal

SSH Config

# ~/.ssh/config
Host github-work
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_work
  IdentitiesOnly yes

Host github-personal
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_personal
  IdentitiesOnly yes

Git-Nutzung

# Arbeits-Repository
git clone git@github-work:company/project.git

# Persönliches Repository
git clone git@github-personal:username/project.git

Multi-Plattform-Konfiguration

# ~/.ssh/config
Host github.com
  User git
  IdentityFile ~/.ssh/id_github

Host gitlab.com
  User git
  IdentityFile ~/.ssh/id_gitlab

Host gitee.com
  User git
  IdentityFile ~/.ssh/id_gitee

Host dev.azure.com
  User git
  IdentityFile ~/.ssh/id_azure

4. SSH-Agent-Verwaltung

Agent starten

eval "$(ssh-agent -s)"

Schlüssel hinzufügen

ssh-add ~/.ssh/id_ed25519
# Enter passphrase: ****

# Hinzugefügte Schlüssel anzeigen
ssh-add -l
# 256 SHA256:xxx... dev@example.com (ED25519)

Automatischer Start (bashrc)

# ~/.bashrc oder ~/.zshrc
if [ -z "$SSH_AUTH_SOCK" ]; then
  eval "$(ssh-agent -s)"
  ssh-add ~/.ssh/id_ed25519 2>/dev/null
fi

Keychain-Persistenz

# macOS: Keychain zum Speichern der Passphrase verwenden
ssh-add --apple-use-keychain ~/.ssh/id_ed25519

# Linux: keychain verwenden
eval "$(keychain --eval id_ed25519)"

5. Jump-Server-Konfiguration

Szenario: Lokal → Jump-Server → Produktionsserver

# ~/.ssh/config
Host jumpbox
  HostName jump.example.com
  User jump-user
  IdentityFile ~/.ssh/id_jump

Host production
  HostName 10.0.1.100
  User deploy
  IdentityFile ~/.ssh/id_prod
  ProxyJump jumpbox

# Direkte Verbindung zum Produktionsserver (geht automatisch über den Jump-Server)
ssh production

Agent-Weiterleitung

Host jumpbox
  HostName jump.example.com
  ForwardAgent yes

Sicherheitshinweis: Agent-Weiterleitung nur aktivieren, wenn du dem Jump-Server vertraust.

6. Sicherheitshärtung

Serverseitige sshd_config

# /etc/ssh/sshd_config
PermitRootLogin no                    # Root-Login verbieten
PasswordAuthentication no             # Passwort-Login verbieten
PubkeyAuthentication yes             # Nur Schlüssel-Login erlauben
AuthorizedKeysFile .ssh/authorized_keys
MaxAuthTries 3                       # Maximale Versuche
LoginGraceTime 30                    # Login-Timeout 30 Sekunden
AllowUsers deploy admin              # Benutzer-Whitelist

Schlüsselberechtigungen

# Privatschlüssel muss 600 sein
chmod 600 ~/.ssh/id_ed25519

# .ssh-Verzeichnis muss 700 sein
chmod 700 ~/.ssh

# authorized_keys muss 600 sein
chmod 600 ~/.ssh/authorized_keys

Schlüsselrotation

# 1. Neuen Schlüssel erstellen
ssh-keygen -t ed25519 -C "dev@example.com" -f ~/.ssh/id_ed25519_new

# 2. Neuen öffentlichen Schlüssel auf allen Servern/Git-Plattformen bereitstellen
ssh-copy-id -i ~/.ssh/id_ed25519_new.pub user@server

# 3. Prüfen, ob der neue Schlüssel funktioniert
ssh -i ~/.ssh/id_ed25519_new user@server

# 4. Alten öffentlichen Schlüssel entfernen
# Server ~/.ssh/authorized_keys bearbeiten, alte Zeile löschen

# 5. Alten Schlüssel löschen
rm ~/.ssh/id_ed25519_old

7. Häufige Probleme und Lösungen

Problem	Ursache	Lösung
`Permission denied`	Öffentlicher Schlüssel nicht bereitgestellt	`ssh-copy-id`
`Too many authentication failures`	Zu viele Schlüssel im Agent	`IdentitiesOnly yes`
`Are you sure you want to continue connecting`	Erste Verbindung	`StrictHostKeyChecking=accept-new`
Langsame Verbindung	Reverse-DNS-Abfrage	`UseDNS no` (serverseitig)
Schlüssel funktioniert nicht	Falsche Berechtigungen	`chmod 600` für Privatschlüssel

Debug-Modus

ssh -vvv user@server.com
# Detaillierte Ausgabe des Verbindungsprozesses, Authentifizierungsfehler lokalisieren