SSH-Schlüssel (Kryptografische SSH-Schlüssel)

1. Überblick über das Konzept und das systemische Problem

Die traditionelle Authentifizierung mittels Login und Passwort auf Remote-Servern weist kritische architektonische Schwachstellen auf: Anfälligkeit für Brute-Force-Angriffe, Abhörangriffe bei Kompromittierung des Kanals (Man-in-the-Middle) sowie der menschliche Faktor (Nutzung schwacher oder wiederverwendeter Passwörter). Sobald Port 22 im öffentlichen Internet erreichbar ist, generieren Botnetze tausende Passwort-Versuche pro Minute.

SSH Keys (Kryptografische SSH-Schlüssel) lösen dieses Problem durch asymmetrische Kryptografie. Der Benutzer erzeugt ein Paar mathematisch verknüpfter Schlüssel:

• Private Key: Wird ausschließlich lokal auf der Entwicklermaschine in einem verschlüsselten Format mit Passphrase gespeichert und niemals über das Netzwerk übertragen.
• Public Key: Wird auf dem Zielserver in der Datei ~/.ssh/authorized_keys platziert.

Während des Handshakes generiert der Server eine zufällige Challenge, die er entweder verschlüsselt oder vom Client unter Verwendung des Private Keys signieren lässt. Die Authentifizierung erfolgt durch den mathematischen Nachweis des Besitzes des Private Keys, ohne dass das eigentliche Geheimnis offengelegt wird.

+------------------+                    +--------------------+
|  Локальний клієнт|                    |  Віддалений сервер |
|  (~/.ssh/id_ed)  |                    |  (~/.ssh/auth_keys)|
+--------+---------+                    +---------+----------+
         |                                        |
         |  1. Запит на з'єднання (User, PubKey)  |
         |--------------------------------------->|
         |                                        | 2. Перевірка наявності
         |                                        |    публічного ключа
         |  3. Криптографічний челендж (Nonce)    |
         |<---------------------------------------|
         |                                        |
         | 4. Підпис nonce приватним ключем       |
         |--------------------------------------->|
         |                                        | 5. Валідація підпису
         |                                        |    публічним ключем
         |  6. Сесія відкрита (Authenticated)    |
         |<---------------------------------------|

2. Architektonische Taxonomie und mentales Modell

Die kryptografischen Algorithmen für SSH haben sich parallel zur Entwicklung der Rechenleistung und des Kryptoanalyse weiterentwickelt:

1. Ed25519 (Edwards-curve Digital Signature Algorithm):
   • Der aktuelle De-facto-Goldstandard der Branche.
   • Basierend auf der elliptischen Kurve Curve25519.
   • Schlüssellänge: 256 Bit.
   • Hohe Resistenz gegen Side-Channel- und Timing-Angriffe, blitzschnelle Ausführungsgeschwindigkeit.
2. ECDSA (Elliptic Curve Digital Signature Algorithm):
   • Verwendet standardisierte NIST-Kurven (z. B. nistp256 oder nistp521).
   • Birgt potenzielle Backdoor-Risiken bei der Auswahl der Generatorparameter von NIST sowie eine kritische Empfindlichkeit gegenüber der Qualität des Zufallszahlengenerators (RNG): Eine Wiederholung des Zufallswerts k legt den Private Key vollständig offen.
3. RSA (Rivest-Shamir-Adleman):
   • Klassischer Algorithmus basierend auf der Faktorisierung großer Primzahlen.
   • Schlüssel mit einer Länge von weniger als 2048 Bit gelten als kompromittiert. Das sichere Minimum liegt bei 4096 Bit.
   • Sehr große Public- und Private-Keys, langsamere Generierung und Signaturerstellung.
4. FIDO2 / Hardware Security Keys (ed25519-sk / ecdsa-sk):
   • Hardware-basierte Authentifizierung über physische Tokens (YubiKey).
   • Der Private Key wird generiert und verlässt niemals den geschützten Chip des Tokens; jede SSH-Sitzung erfordert einen physischen Touch.

3. Technischer Pipeline und interne Mechanik

Generierung und Deployment eines sicheren Schlüssels

Generierung eines produktionsreifen Ed25519-Schlüssels mit erhöhter Anzahl an Runden für die Schlüsselableitung (KDF), um Schutz vor GPU-basiertem Brute-Force gegen die Passphrase zu bieten:

# Генерація Ed25519 з коментарем та 100 раундами KDF
ssh-keygen -t ed25519 -a 100 -C "admin@production-cluster" -f ~/.ssh/id_ed25519_prod

Kopieren des Public Keys auf den Remote-Server:

ssh-copy-id -i ~/.ssh/id_ed25519_prod.pub deploy@vps.internal.net

Struktur der Dateisystem-Berechtigungen unter Linux

Inkorrekte Zugriffsrechte sind die Ursache für 90 % der Fehler bei der SSH-Authentifizierung (Permission denied (publickey)):

# Локальна машина клієнта:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519_prod
chmod 644 ~/.ssh/id_ed25519_prod.pub
chmod 600 ~/.ssh/config

# Віддалений сервер:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh

Konfiguration des Clients (~/.ssh/config)

Um die Übertragung langer Kommandozeilen-Flags zu vermeiden, wird eine deklarative Client-Konfiguration verwendet:

Host prod-node-01
    HostName 198.51.100.24
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_prod
    IdentitiesOnly yes
    ServerAliveInterval 60
    ServerAliveCountMax 3

Host bastion-jumphost
    HostName 203.0.113.10
    User gatekeeper
    IdentityFile ~/.ssh/id_ed25519_bastion

Host internal-db
    HostName 10.0.4.15
    User postgres
    ProxyJump bastion-jumphost
    IdentityFile ~/.ssh/id_ed25519_db

4. Praktische Engineering-Szenarien in der Produktion

01. Passwortloser Zugriff für automatisierte CI/CD-Pipelines

In Umgebungen wie GitHub Actions oder GitLab CI/CD erfolgt das Deployment automatisch über einen dedizierten technischen SSH-Key. Der Private Key wird in den verschlüsselten Secrets des Repositories gespeichert, während der Public Key auf dem Server über die Direktive command="..." in authorized_keys an eine eingeschränkte Shell oder ein spezifisches Kommando gebunden wird:

command="/usr/local/bin/deploy-webhook.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-ed25519 AAAAC3NzaC1lZDI1NTE5... ci-deploy-key

Selbst wenn das CI/CD-Secret kompromittiert wird, kann ein Angreifer nur das deterministische Deployment-Skript ausführen, aber keine beliebigen Befehle im Terminal.

02. Zugriff auf isolierte Infrastruktur-Nodes über Bastion (ProxyJump)

In VPCs haben private Datenbanken oder AI-Agent-Server keine öffentlichen IP-Adressen. Ingenieure verbinden sich über einen Zwischen-Bastion-Host, ohne den Private Key auf den Bastion exportieren zu müssen:

ssh -J gatekeeper@bastion.example.com deploy@10.0.1.50

SSH tunneln den TCP-Traffic auf Socket-Ebene über den Proxy-Knoten und verschlüsseln die Sitzung mit dem Endschlüssel des Ziel-Servers (ProxyJump gibt den Traffic-Inhalt nicht an den Bastion preis).

03. FIDO2-Hardware-Keys für Zero-Trust-Infrastrukturen

In hochbelasteten oder regulierten Fintech-Systemen sind Entwickler verpflichtet, Hardware-Tokens wie YubiKey zu verwenden. Es wird ein Schlüssel des Typs ed25519-sk erstellt. Jede Aktion wie git push oder jede SSH-Sitzung erfordert einen physischen Tastendruck auf den Sensor des Tokens. Dies eliminiert die Bedrohung durch den Diebstahl von Private Keys durch Infostealer oder schädliche Software auf dem Laptop des Entwicklers vollständig.

5. Fallstricke, häufige Fehler und Sicherheit

1. Schlüsselgenerierung ohne Passphrase: Die Speicherung eines Private Keys ohne ein starkes Passwort stellt eine kritische Bedrohung dar: Jeder schädliche Prozess, jedes Skript oder jeder physische Zugriff auf einen entsperrten Laptop ermöglicht es, den Private Key sofort zu kopieren und Zugang zur gesamten Infrastruktur zu erhalten. Schützen Sie Schlüssel immer mit einem Passwort und nutzen Sie ssh-agent.
2. Unkontrollierter Sprawl in authorized_keys: Im Laufe der Zeit sammeln sich Dutzende von Schlüsseln ehemaliger Entwickler oder temporärer Auftragnehmer in der Datei an. Fehlende regelmäßige Audits öffnen Hintertüren. Nutzen Sie zentralisiertes Schlüsselmanagement über Ansible, Teleport, HashiCorp Vault oder eine SSH Certificate Authority (CA).
3. Verwendung von SSH Agent Forwarding (-A): Die Aktivierung von ForwardAgent yes in der globalen Konfiguration erlaubt es Remote-Maschinen, auf Ihren lokalen ssh-agent-Socket zuzugreifen. Aktivieren Sie Agent Forwarding niemals global; verwenden Sie stattdessen ProxyJump oder ssh-add -c, um jede Nutzung des Schlüssels einzeln zu bestätigen.