Wo werden SSH-Schlüssel in Linux gespeichert — und wie man sie sicher verwaltet

SSH (Secure Shell) ist eines der kritischsten Tools im Linux-Ökosystem. Systemadministratoren, Entwickler und DevOps-Ingenieure verlassen sich täglich darauf für Remote-Serverzugriff, sichere Dateiübertragungen, Deployment-Automatisierung und Infrastrukturverwaltung. Während die meisten Benutzer SSH über einen einfachen Terminalbefehl nutzen, liegt das eigentliche Sicherheitsgerüst in SSH-Schlüsselpaaren — kryptografischen Anmeldedaten, die passwortlose Authentifizierung, automatisierte Workflows und gehärtete Zugriffskontrolle ermöglichen.

Egal ob Sie eine einzelne VPS Hosting Instanz verwalten oder den Zugriff über Dutzende von Dedicated Servers orchestrieren — zu verstehen, wo genau SSH-Schlüssel gespeichert sind und wie man sie richtig verwaltet, ist nicht optional. Es ist eine grundlegende Sicherheitsanforderung.

Dieser Leitfaden behandelt alles: Standard-Speicherorte für Schlüssel, systemweite Host-Schlüssel, benutzerdefinierte Konfigurationen, Berechtigungsanforderungen und Best Practices für sichere Schlüsselverwaltung.

Was sind SSH-Schlüssel und warum sind sie wichtig?

SSH-Schlüssel verwenden asymmetrische Kryptographie zur Authentifizierung von Benutzern und Servern. Jedes Schlüsselpaar besteht aus:

• Privater Schlüssel — wird geheim auf dem Client-Rechner gespeichert, niemals weitergegeben
• Öffentlicher Schlüssel — wird auf dem Remote-Server platziert, um die Identität zu überprüfen

Wenn Sie sich mit einem Server verbinden, verwendet SSH einen kryptographischen Handshake, um zu überprüfen, dass Sie den privaten Schlüssel besitzen, der dem öffentlichen Schlüssel auf dem Server entspricht – ohne den privaten Schlüssel jemals zu übertragen. Dies ist grundlegend sicherer als passwortbasierte Authentifizierung.

Standardspeicherort für SSH-Schlüssel (Benutzerschlüssel)

Für jeden Standard-Linux-Benutzer werden SSH-Schlüssel in einem versteckten Verzeichnis im Home-Ordner gespeichert:

~/.ssh/

Dies erweitert sich zum vollständigen Pfad:

/home/username/.ssh/

Für den Root-Benutzer speziell:

/root/.ssh/

Häufige Dateien in ~/.ssh/

Wenn Sie ssh-keygen ausführen, werden Schlüssel standardmäßig in dieses Verzeichnis geschrieben, es sei denn, Sie geben während der Schlüsselerzeugung explizit einen anderen Pfad an.

System-weite SSH-Schlüsselspeicherorte (Host-Schlüssel)

Neben Benutzerschlüsseln verwaltet der SSH Daemon (sshd) — die serverseitige Komponente — seinen eigenen Satz von Host-Schlüsseln. Diese werden systemweit unter folgender Adresse gespeichert:

/etc/ssh/

Host-Schlüsseldateien in /etc/ssh/

Diese Host-Schlüssel dienen einem anderen Zweck als Benutzerschlüssel. Wenn sich ein Client zum ersten Mal mit einem Server verbindet, präsentiert der Server seinen öffentlichen Host-Schlüssel. Der Client speichert diesen Fingerabdruck in ~/.ssh/known_hosts. Bei nachfolgenden Verbindungen überprüft SSH, ob der Fingerabdruck übereinstimmt — zum Schutz vor Man-in-the-Middle-Angriffen.

> Wichtig: Host-Schlüssel werden während der SSH-Server-Installation automatisch generiert. Sie sollten sie niemals manuell erstellen müssen, aber Sie sollten wissen, wo sie sich befinden, um sie zu überprüfen und zu sichern.

Custom SSH Key Locations

Sie sind nicht auf das Standard-Verzeichnis ~/.ssh/ beschränkt. SSH-Schlüssel können überall im Dateisystem generiert und gespeichert werden. Um einen Schlüssel an einem nicht standardmäßigen Ort zu verwenden, geben Sie ihn explizit an:

ssh -i /path/to/custom_key user@host

Verwendung von ~/.ssh/config für mehrere Schlüssel

Die Verwaltung mehrerer Server, Projekte oder Benutzerkonten wird mit einer ordnungsgemäß konfigurierten ~/.ssh/config-Datei viel übersichtlicher. Dies ermöglicht es Ihnen, Pro-Host-Einstellungen zu definieren, einschließlich welcher Schlüssel verwendet werden soll:

Host production-server
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/production_ed25519

Host staging-server
    HostName 203.0.113.20
    User deploy
    IdentityFile ~/.ssh/staging_ed25519

Host github.com
    User git
    IdentityFile ~/.ssh/github_key

Mit dieser Konfiguration verwendet ssh production-server automatisch den richtigen Schlüssel ohne zusätzliche Flags.

Wie SSH-Schlüssel verwendet werden: Client vs. Server

Ausgehende Verbindungen (Client-Seite)

Wenn Sie eine SSH-Verbindung initiieren, sucht der SSH-Client standardmäßig nach privaten Schlüsseln in ~/.ssh/. Diese Schlüssel werden verwendet, um Sie gegenüber dem Remote-Server zu authentifizieren.

Tools, die SSH-Client-Schlüssel verwenden, sind:

• ssh — direkter Remote-Shell-Zugriff
• scp — sichere Dateiübertragung
• rsync — Dateisynchronisierung über SSH
• git — bei Verwendung von SSH-basierten Remote-Repositories

Eingehende Verbindungen (Server-Seite)

Auf dem Server prüft SSH eine bestimmte Datei, um zu bestimmen, welche Benutzer berechtigt sind, sich zu verbinden:

~/.ssh/authorized_keys

Diese Datei enthält einen öffentlichen Schlüssel pro Zeile. Jeder Eintrag gewährt dem Inhaber des entsprechenden privaten Schlüssels die Berechtigung, sich als dieser Benutzer anzumelden.

Praktisches Beispiel: Wenn Benutzer alice sich per SSH auf einem Server als Benutzer webadmin anmelden möchte, muss Alices öffentlicher Schlüssel in /home/webadmin/.ssh/authorized_keys vorhanden sein — nicht in Alices eigenem Home-Verzeichnis auf diesem Server.

Dateiberechtigungen — Kritisch für SSH-Sicherheit

Hier machen viele Administratoren teure Fehler. SSH ist absichtlich streng bei Dateiberechtigungen. Wenn die Berechtigungen zu offen sind, wird SSH Ihre Schlüssel stillschweigend nicht verwenden oder Anmeldeversuche ganz ablehnen.

Erforderliche Berechtigungseinstellungen

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
chmod 600 ~/.ssh/config

Berechtigungsreferenztabelle

Um Berechtigungen in einem Befehl zu beheben:

chmod 700 ~/.ssh && chmod 600 ~/.ssh/* && chmod 644 ~/.ssh/*.pub

SSH-Schlüssel sicher generieren

Bevorzugen Sie immer Ed25519 gegenüber RSA für neue Schlüssel. Ed25519 bietet stärkere Sicherheit mit kürzeren Schlüsselgrößen und besserer Leistung.

ssh-keygen -t ed25519 -C "your_email@example.com"

Für Legacy-Systeme, die RSA erfordern, verwenden Sie mindestens 4096 Bits:

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Legen Sie immer eine Passphrase fest, wenn Sie dazu aufgefordert werden. Eine Passphrase verschlüsselt den privaten Schlüssel auf der Festplatte, sodass ein Angreifer den Schlüssel auch bei Zugriff auf Ihr Dateisystem nicht ohne die Passphrase verwenden kann.

Verwalten von Schlüsseln mit ssh-agent

Das wiederholte Eingeben Ihrer Passphrase bei jeder Verwendung eines SSH-Schlüssels wird unpraktisch. ssh-agent löst dies, indem entschlüsselte Schlüssel für die Dauer Ihrer Sitzung im Speicher zwischengespeichert werden.

Starten von ssh-agent und Hinzufügen eines Schlüssels

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Sie werden einmalig zur Eingabe der Passphrase aufgefordert. Danach verwenden SSH-Operationen den zwischengespeicherten Schlüssel automatisch.

Nützliche ssh-agent-Befehle

# List currently loaded keys
ssh-add -l

# Remove a specific key from the agent
ssh-add -d ~/.ssh/mykey

# Remove all keys from the agent
ssh-add -D

Öffentliche Schlüssel auf Remote-Servern kopieren

Die einfachste Möglichkeit, Ihren öffentlichen Schlüssel auf einem Remote-Server zu installieren, ist mit ssh-copy-id:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@remote-host

Dies fügt Ihren öffentlichen Schlüssel zu ~/.ssh/authorized_keys auf dem Remote-Server an und setzt die richtigen Berechtigungen automatisch.

Wenn ssh-copy-id nicht verfügbar ist, führen Sie es manuell durch:

cat ~/.ssh/id_ed25519.pub | ssh user@remote-host "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Überprüfung und Debugging von SSH-Schlüsselproblemen

Ausführliches Verbindungsprotokoll

Wenn die SSH-Authentifizierung fehlschlägt, zeigt der ausführliche Modus genau, was passiert:

ssh -v user@host

Für noch mehr Details:

ssh -vvv user@host

Diese Ausgabe zeigt, welche Identitätsdateien versucht wurden, ob der Agent konsultiert wurde und wo die Authentifizierung fehlgeschlagen ist.

Überprüfen Sie das SSH-Protokoll auf der Serverseite

Auf dem Remote-Server werden SSH-Authentifizierungsereignisse protokolliert in:

# Debian/Ubuntu
tail -f /var/log/auth.log

# CentOS/RHEL/Fedora
tail -f /var/log/secure

# Systems using journald
journalctl -u sshd -f

Überprüfen Sie Ihre authorized_keys-Datei

# Check the file exists and has correct permissions
ls -la ~/.ssh/authorized_keys

# View its contents
cat ~/.ssh/authorized_keys

# Count how many keys are authorized
grep -c "ssh-" ~/.ssh/authorized_keys

SSH Key Security Best Practices

Ordnungsgemäße Schlüsselverwaltung geht über das bloße Wissen hinaus, wo Dateien gespeichert sind. Befolgen Sie diese Praktiken auf jedem System, das Sie verwalten:

1. Verwenden Sie einen Schlüssel pro Zweck

Verwenden Sie niemals denselben SSH-Schlüssel in verschiedenen Umgebungen, für verschiedene Clients oder Projekte. Verwenden Sie separate Schlüssel für persönlichen Zugriff, Bereitstellungsautomatisierung und gemeinsamen Teamzugriff.

2. Schlüssel regelmäßig wechseln

Behandeln Sie SSH-Schlüssel wie Passwörter — wechseln Sie sie regelmäßig, besonders nach dem Ausscheiden von Teammitgliedern oder vermuteten Kompromittierungen.

3. Audit authorized_keys Dateien

Überprüfen Sie regelmäßig, welche öffentlichen Schlüssel auf jedem Server autorisiert sind. Entfernen Sie alle Schlüssel, die zu ehemaligen Mitarbeitern, veralteter Automatisierung oder unbekannten Quellen gehören:

# Find all authorized_keys files on a system
find / -name "authorized_keys" 2>/dev/null

4. Passwortauthentifizierung deaktivieren

Sobald SSH-Schlüssel konfiguriert sind, deaktivieren Sie die passwortbasierte SSH-Anmeldung vollständig in /etc/ssh/sshd_config:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password

Starten Sie sshd nach Änderungen neu:

systemctl restart sshd

5. Root-Schlüsselverwendung einschränken

Vermeiden Sie die Verwendung von Root-SSH-Schlüsseln in mehreren Umgebungen. Verwenden Sie stattdessen sudo-aktivierte Benutzerkonten mit individuellen Schlüsseln.

6. Verwenden Sie zertifikatbasierte Authentifizierung für große Infrastrukturen

Für große Infrastrukturen sollten Sie SSH-Zertifikate (über eine SSH-Zertifizierungsstelle) anstelle der Verwaltung einzelner authorized_keys Einträge in Betracht ziehen. Dies vereinfacht die Zugriffsverwaltung auf vielen Servern erheblich.

SSH Keys in Cloud and Hosting Environments

Bei der Bereitstellung von Servern in Cloud- oder verwalteten Hosting-Umgebungen wird SSH-Schlüsselverwaltung noch kritischer. Die meisten Plattformen — einschließlich VPS Hosting Anbieter — ermöglichen es Ihnen, einen öffentlichen Schlüssel zum Zeitpunkt der Bereitstellung einzufügen, was Ihnen sofortigen sicheren Zugriff gibt, ohne jemals ein Passwort festzulegen.

Für Teams, die mehrere Umgebungen verwalten, sollten Sie Ihre SSH-Schlüsselstrategie mit einem strukturierten VPS Control Panels Setup kombinieren, das die Benutzerverwaltung und Zugriffskontrolle über Ihre Infrastruktur vereinfachen kann.

Wenn Sie Webanwendungen oder Dienste ausführen, die eine sichere Kommunikation über SSH hinaus erfordern, stellt die Kopplung Ihres Server-Setups mit ordnungsgemäß konfigurierten SSL Certificates eine End-to-End-Verschlüsselung für den gesamten Datenverkehr sicher — nicht nur für den administrativen Zugriff.

Für Teams, die sich auf Email Hosting neben ihrer Server-Infrastruktur verlassen, erstreckt sich die SSH-Schlüsselverwaltung auf die Sicherung der Systeme, die Ihre E-Mails verarbeiten — ein weiterer Grund, warum konsistente Schlüsselhygiene über alle Server hinweg wichtig ist.

Schnellreferenz: SSH-Schlüsseldatei-Speicherorte

Fazit

Zu verstehen, wo SSH-Schlüssel in Linux gespeichert sind — und sie diszipliniert zu verwalten — ist eine der wichtigsten Fähigkeiten für jeden, der mit Servern arbeitet, egal ob Sie ein einzelner Entwickler oder Teil eines großen Operations-Teams sind.

Zusammenfassung der wichtigsten Erkenntnisse:

• Benutzerschlüssel befinden sich in ~/.ssh/ und werden für die clientseitige Authentifizierung verwendet
• Host-Schlüssel befinden sich in /etc/ssh/ und identifizieren den Server für verbindende Clients
• authorized_keys kontrolliert den eingehenden Zugriff — überprüfen Sie ihn regelmäßig
• Dateiberechtigungen sind nicht verhandelbar — falsche Berechtigungen unterbrechen SSH stillschweigend
• Ed25519 ist der bevorzugte Schlüsseltyp für die Generierung neuer Schlüssel
• Verwenden Sie immer Passphrasen und ssh-agent für die tägliche Schlüsselverwaltung
• Rotieren und überprüfen Sie Schlüssel als Teil Ihrer regelmäßigen Sicherheitshygiene

Auf Produktionssystemen — egal ob Sie Dedicated Servers oder gemeinsame Infrastruktur betreiben — ist Missverwaltung von SSH-Schlüsseln einer der häufigsten Vektoren für unbefugten Zugriff. Die Investition von Zeit, um dies richtig zu machen, zahlt sich in Sicherheit, Zuverlässigkeit und Seelenfrieden aus.

Behandeln Sie Ihre SSH-Schlüssel mit der gleichen Sorgfalt, die Sie jedem kritischen Anmeldedaten geben würden. Denn genau das sind sie.