SSH Public-Key-Authentifizierung: Vom Fedora-Client zum RHEL-Server

Was ist das hier – und für wen?⌗

Diese Anleitung erklärt, wie du eine sichere, passwortlose SSH-Verbindung zwischen einem Fedora-Client und einem RHEL 10-Server einrichtest. Dabei wird nicht nur Schritt für Schritt erklärt was du eingibst, sondern auch warum – damit du das Konzept verstehst und auf andere Systeme übertragen kannst.

Die Anleitung ist in zwei Teile gegliedert:

1. Das Konzept – Was ist SSH-Public-Key-Authentifizierung, und warum ist sie sicherer als ein Passwort?
2. Die Umsetzung – Konkret auf Fedora (Client) und RHEL 10 (Server), inklusive SELinux und firewalld.

Zielgruppe: Linux-Einsteiger und Fortgeschrittene, die verstehen wollen, was sie tun – nicht nur kopieren.

Das Konzept: Wie funktioniert Public-Key-Authentifizierung?⌗

Das Problem mit Passwörtern⌗

Wenn du dich per SSH mit einem Passwort anmeldest, passiert Folgendes:

1. Du tippst dein Passwort
2. Es wird verschlüsselt übers Netzwerk gesendet
3. Der Server prüft es gegen seine Benutzerdatenbank

Das klingt sicher – ist es aber nicht vollständig. Das Passwort muss irgendwo gespeichert sein. Automatisierte Bots scannen das Internet rund um die Uhr und versuchen Millionen von Passwörtern (Brute-Force). Wer Port 22 offen hat, bekommt diese Angriffe regelmäßig mit.

Die Lösung: Ein Schlüsselpaar⌗

Public-Key-Kryptografie löst dieses Problem mathematisch elegant. Du erzeugst ein Schlüsselpaar:

Die Magie: Der Server kennt deinen Public Key und stellt dir eine mathematische Rechenaufgabe, die nur dein privater Schlüssel lösen kann. Kein Passwort wandert übers Netzwerk. Kein Brute-Force-Angriff kann helfen – die Schlüssellänge macht das rechnerisch unmöglich.

Welcher Algorithmus? Ed25519, nicht RSA⌗

Es gibt verschiedene kryptografische Algorithmen für SSH-Schlüssel:

Für alle neuen Setups gilt: Ed25519.

Was ist eine Passphrase – und brauche ich sie?⌗

Eine Passphrase verschlüsselt deinen privaten Schlüssel auf der Festplatte. Ohne Passphrase ist der private Schlüssel eine ungesicherte Datei – wer sie kopiert, kann sich sofort als du ausgeben. Mit Passphrase ist sie nutzlos ohne das Passwort.

Das klingt umständlich, aber dafür gibt es den SSH-Agent – er speichert deinen entsperrten Schlüssel im Arbeitsspeicher, sodass du die Passphrase nur einmal pro Sitzung eingibst.

Faustregel:

• Heimnetz, nur du, kein Risiko → Passphrase optional
• Produktivserver, sensible Daten → Passphrase immer

Voraussetzungen⌗

Client (Fedora)⌗

• Fedora Linux (beliebige aktuelle Version)
• Terminal / Shell (z. B. GNOME Terminal, Konsole, Kitty)
• OpenSSH Client – auf Fedora standardmäßig installiert

# Prüfen ob vorhanden:
ssh -V

Server (RHEL 10)⌗

• RHEL 10 (oder kompatibel: AlmaLinux 10, Rocky Linux 10)
• openssh-server installiert und aktiv
• Physischer Zugriff oder bestehende Verbindung für die Erstkonfiguration
• Ein regulärer Benutzer mit sudo-Rechten (kein Root!)

# Auf dem Server prüfen:
rpm -q openssh-server
sudo systemctl status sshd

Wichtig: Führe diese Anleitung nicht als root durch – weder auf dem Client noch auf dem Server. SSH-Keys sollten immer für den jeweiligen Benutzer erstellt werden.

Teil 1: Client-Seite (Fedora)⌗

Schritt 1: SSH-Schlüsselpaar erzeugen⌗

ssh-keygen -t ed25519 -C "$(whoami)@$(hostname)-$(date +%Y-%m)"

Was bedeuten die Parameter?

• -t ed25519 – Algorithmus (siehe oben)
• -C "..." – Kommentar, der im Public Key gespeichert wird. Der Befehl setzt automatisch benutzer@rechner-2026-05 ein – so erkennst du später auf dem Server, welcher Key von welchem Gerät stammt.

Der Ablauf sieht so aus:

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/dein-user/.ssh/id_ed25519): [Enter]
Enter passphrase (empty for no passphrase): [Passphrase eingeben]
Enter same passphrase again: [Wiederholen]
Your identification has been saved in /home/dein-user/.ssh/id_ed25519
Your public key has been saved in /home/dein-user/.ssh/id_ed25519.pub

Der Standardpfad ~/.ssh/id_ed25519 ist für die meisten Setups richtig. Drücke einfach Enter.

Mehrere Server, mehrere Schlüssel? Wenn du verschiedene Server oder Rollen hast, kannst du dedizierte Schlüssel erzeugen:

ssh-keygen -t ed25519 -f ~/.ssh/id_rhel_server -C "jay@laptop-rhel-prod"

Schritt 2: Die erzeugten Dateien verstehen⌗

ls -la ~/.ssh/

drwx------. 2 jay jay 4096 May 25 10:00 .
drwx------. 25 jay jay 4096 May 25 09:55 ..
-rw-------. 1 jay jay  411 May 25 10:00 id_ed25519      ← privater Schlüssel (geheim!)
-rw-r--r--. 1 jay jay  100 May 25 10:00 id_ed25519.pub  ← öffentlicher Schlüssel

Die Berechtigungen sind entscheidend:

Schritt 3: Den Public Key anzeigen⌗

cat ~/.ssh/id_ed25519.pub

Ausgabe (Beispiel):

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBdM2e... jay@fedora-laptop-2026-05

Das ist der Text, der später auf den Server muss. Er ist eine einzige Zeile.

Teil 2: Server-Seite (RHEL 10)⌗

Schritt 4: IP-Adresse des Servers herausfinden⌗

Auf dem Server (physisch oder per Konsole):

ip a show

Suche nach einer Zeile wie inet 192.168.178.42/24 – das ist deine Server-IP im lokalen Netz.

Schritt 5: Public Key auf den Server übertragen⌗

Die einfachste Methode – ssh-copy-id:

ssh-copy-id -i ~/.ssh/id_ed25519.pub jay@192.168.178.42

Dieser Befehl:

1. Verbindet sich einmalig per Passwort mit dem Server
2. Legt automatisch ~/.ssh/authorized_keys an (falls nicht vorhanden)
3. Setzt die richtigen Berechtigungen

Du wirst einmalig nach dem Passwort des Benutzers auf dem Server gefragt – danach nie wieder.

Alternative: Manuell per USB-Stick (wenn kein Netzwerkzugriff möglich)

Auf dem Client (Public Key auf Stick kopieren):

cp ~/.ssh/id_ed25519.pub /run/media/$USER/STICKNAME/

Auf dem Server (Key eintragen):

mkdir -p ~/.ssh
chmod 700 ~/.ssh
cat /run/media/jay/STICKNAME/id_ed25519.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
chown -R jay:jay ~/.ssh

Wichtig: >> (doppeltes Größer-als) hängt den Key an, ohne bestehende Keys zu überschreiben. Nie > verwenden!

Schritt 6: Berechtigungen auf dem Server kontrollieren⌗

Das ist die häufigste Fehlerquelle! SSH verweigert den Key-Login, wenn die Berechtigungen falsch sind:

ls -la ~/.ssh/
stat ~/.ssh/authorized_keys

Erwartete Ausgabe:

drwx------. 2 jay jay   29 May 25 10:15 .ssh
-rw-------. 1 jay jay  100 May 25 10:15 authorized_keys

Falls etwas falsch ist, korrigieren:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R jay:jay ~/.ssh

Schritt 7: SELinux-Kontext prüfen (RHEL-spezifisch!)⌗

RHEL 10 läuft standardmäßig mit SELinux im Enforcing-Modus. SSH prüft nicht nur die Dateiberechtigungen, sondern auch die SELinux-Sicherheitskontexte. Ein falscher Kontext führt dazu, dass der Key kommentarlos ignoriert wird.

ls -Z ~/.ssh/

Korrekte Ausgabe:

unconfined_u:object_r:ssh_home_t:s0 .
unconfined_u:object_r:ssh_home_t:s0 authorized_keys

Der Typ muss ssh_home_t sein. Falls nicht (z. B. nach manuellem Kopieren):

restorecon -R -v ~/.ssh/

Das setzt den SELinux-Kontext auf den korrekten Wert zurück.

Warum passiert das? Wenn du Dateien von einem USB-Stick oder per cp aus einem anderen Verzeichnis kopierst, übernimmt die neue Datei den SELinux-Kontext des Quellverzeichnisses – nicht den des Zielverzeichnisses. restorecon korrigiert das.

Teil 3: SSH-Server konfigurieren (RHEL 10)⌗

Schritt 8: sshd_config anpassen⌗

Auf RHEL 10 nutzt man am besten Drop-in-Konfigurationsdateien statt die Hauptdatei zu bearbeiten. Das hat Vorteile:

• Systemupdates überschreiben deine Änderungen nicht
• Übersichtlicher: jede Funktion in einer eigenen Datei
• Einfacher rückgängig zu machen

sudo nano /etc/ssh/sshd_config.d/99-custom.conf

Inhalt:

# Grundlegende Verbindungsoptionen
Port 22
AddressFamily any
ListenAddress 0.0.0.0

# Authentifizierung
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication yes       # Erst nach erfolgreichem Key-Test auf "no" setzen!

# Sicherheit
PermitRootLogin no               # Root-Login grundsätzlich verbieten
MaxAuthTries 3                   # Max. 3 Fehlversuche pro Verbindung
LoginGraceTime 30                # 30 Sekunden zum Einloggen

# Verbindungsqualität
ClientAliveInterval 120          # Alle 120s Keepalive senden
ClientAliveCountMax 3            # 3 ausbleibende Antworten → Verbindung trennen

Warum PasswordAuthentication yes lassen? Solange du den Key-Login nicht erfolgreich getestet hast, lass Passwort-Auth aktiv. Sonst sperrst du dich aus, wenn etwas mit dem Key nicht stimmt.

Schritt 9: Konfiguration auf Syntaxfehler prüfen⌗

Immer vor dem Neustart!

sudo sshd -t

Keine Ausgabe = keine Fehler. Bei einem Fehler wird die genaue Zeile angezeigt. Erst wenn dieser Befehl sauber durchläuft, den Dienst neu starten.

Schritt 10: sshd neu starten⌗

sudo systemctl restart sshd
sudo systemctl status sshd

Schritt 11: firewalld prüfen (RHEL-spezifisch!)⌗

RHEL 10 verwendet firewalld als Standard-Firewall. SSH (Port 22) ist in der Regel bereits freigegeben, aber prüfen schadet nicht:

sudo firewall-cmd --list-all

In der Ausgabe muss services: die Zeile ssh enthalten. Falls nicht:

sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

Schritt 12: Lauscht sshd auf dem richtigen Port?⌗

sudo ss -tnlp | grep sshd

Erwartete Ausgabe:

LISTEN  0  128  0.0.0.0:22   0.0.0.0:*   users:(("sshd",pid=1234,fd=3))

Teil 4: Verbindung testen⌗

Schritt 13: Erster Login per Key⌗

Zurück auf dem Client (Fedora):

ssh jay@192.168.178.42

#oder mit hostname
ssh jay@rhel-server

Beim ersten Verbindungsaufbau erscheint:

The authenticity of host '192.168.178.42 (192.168.178.42)' can't be established.
ED25519 key fingerprint is SHA256:aBcDe1234...
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Gib yes ein. Der Fingerprint des Servers wird in ~/.ssh/known_hosts gespeichert. Beim nächsten Mal wird er automatisch verglichen – ändert sich der Fingerprint unerwartet, warnt SSH dich (möglicher Man-in-the-Middle-Angriff).

Bei Erfolg bist du eingeloggt, ohne Passwort (oder nur mit deiner Passphrase).

Schritt 14: Verbose-Modus zur Fehlersuche⌗

Wenn es nicht klappt, gibt -v (oder -vvv für noch mehr Details) detaillierte Ausgaben:

ssh -v jay@192.168.178.42

Relevante Zeilen in der Ausgabe:

debug1: Offering public key: /home/jay/.ssh/id_ed25519 ED25519 SHA256:...
debug1: Server accepts key: ...
debug1: Authentication succeeded (publickey).

Falls stattdessen Permission denied (publickey) erscheint, hilft die Fehlersuche im nächsten Abschnitt.

Teil 5: SSH bequem nutzen – die ~/.ssh/config⌗

Statt jedes Mal IP-Adresse, Benutzername und ggf. Schlüsseldatei einzutippen, legt man eine Klientenkonfiguration an:

nano ~/.ssh/config

# RHEL-Produktivserver
Host rhel-server
    HostName 192.168.178.42
    User jay
    IdentityFile ~/.ssh/id_ed25519
    Port 22

# Zweiter Server mit eigenem Key
Host dev-server
    HostName 192.168.178.100
    User developer
    IdentityFile ~/.ssh/id_rhel_dev
    Port 22

Berechtigungen setzen:

chmod 600 ~/.ssh/config

Ab jetzt reicht:

ssh rhel-server

Teil 6: SSH-Agent – Passphrase nur einmal eingeben⌗

Der SSH-Agent ist ein Hintergrundprozess, der deinen entsperrten privaten Schlüssel im Arbeitsspeicher hält. Du gibst die Passphrase einmal ein – dann kümmert er sich für den Rest der Sitzung.

Auf Fedora mit GNOME (empfohlen)⌗

GNOME Keyring übernimmt die SSH-Agent-Funktion automatisch. Du musst nichts konfigurieren – beim ersten SSH-Verbindungsaufbau erscheint ein grafischer Dialog für die Passphrase, und GNOME merkt sie sich für die Session.

Terminal-basiert (für alle Desktops)⌗

# Agent starten (meist schon aktiv in der GNOME-Session)
eval "$(ssh-agent -s)"

# Schlüssel hinzufügen
ssh-add ~/.ssh/id_ed25519

Passphrase einmalig eingeben → erledigt für diese Terminal-Sitzung.

# Aktive Keys anzeigen
ssh-add -l

# Key nach 8 Stunden automatisch entfernen (empfohlen für Sicherheit)
ssh-add -t 28800 ~/.ssh/id_ed25519

Teil 7: Passwort-Login deaktivieren (optional, aber empfohlen)⌗

Nachdem der Key-Login erfolgreich getestet wurde, kannst du Passwort-Auth abschalten. Das eliminiert Brute-Force-Angriffe vollständig.

Auf dem Server:

sudo nano /etc/ssh/sshd_config.d/99-custom.conf

Zeile ändern:

PasswordAuthentication no

sudo sshd -t           # Syntaxcheck
sudo systemctl restart sshd

Warnung: Stelle sicher, dass der Key-Login funktioniert, bevor du das tust. Öffne eine zweite SSH-Session als Test. Wenn du dich ausgesperrt hast, brauchst du physischen Zugriff oder Out-of-Band-Konsole (IPMI/iDRAC).

Fehlersuche⌗

„Permission denied (publickey)"⌗

Die häufigsten Ursachen – in dieser Reihenfolge prüfen:

1. Falsche Berechtigungen auf dem Server:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

2. Falscher SELinux-Kontext (RHEL-spezifisch):

ls -Z ~/.ssh/authorized_keys
# Muss ssh_home_t zeigen
restorecon -R -v ~/.ssh/

3. Public Key nicht korrekt eingetragen:

cat ~/.ssh/authorized_keys
# Muss die Zeile aus id_ed25519.pub enthalten (eine Zeile, kein Umbruch)

4. Falsche Konfiguration in sshd_config:

sudo grep -i pubkeyauth /etc/ssh/sshd_config /etc/ssh/sshd_config.d/*.conf
# Muss "PubkeyAuthentication yes" zeigen

5. Logs auf dem Server prüfen:

sudo journalctl -u sshd -n 50
# Oder:
sudo tail -f /var/log/secure

„Connection refused"⌗

# Läuft sshd?
sudo systemctl status sshd

# Lauscht sshd auf Port 22?
sudo ss -tnlp | grep :22

# Blockiert die Firewall?
sudo firewall-cmd --list-all

„WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!"⌗

Das bedeutet: Der Fingerprint des Servers hat sich geändert – entweder weil der Server neu aufgesetzt wurde, oder (selten, ernst nehmen!) weil jemand dazwischensitzt.

Wenn du weißt, dass der Server neu aufgesetzt wurde:

ssh-keygen -R 192.168.178.42

Das entfernt den alten Eintrag aus ~/.ssh/known_hosts. Beim nächsten Verbindungsaufbau wird der neue Fingerprint eingetragen.

Sicherheits-Checkliste⌗

Bevor du den Server ins Netz stellst:

• PermitRootLogin no ist gesetzt
• PubkeyAuthentication yes ist gesetzt
• PasswordAuthentication no ist gesetzt (nach erfolgreichem Key-Test)
• MaxAuthTries 3 oder ähnlich gesetzt
• firewalld ist aktiv, SSH ist die einzige offene Regel (außer was sonst gebraucht wird)
• SELinux ist aktiv (getenforce → Enforcing)
• Private Key auf dem Client hat Passphrase
• Jeder Benutzer hat seinen eigenen Key – keine geteilten Keys

Zusammenfassung⌗

SSH-Public-Key-Authentifizierung besteht aus drei Bausteinen:

1. Ein Schlüsselpaar erzeugen (Client) – ssh-keygen -t ed25519
2. Den Public Key übertragen (Server) – ssh-copy-id
3. Server korrekt konfigurieren – PubkeyAuthentication yes, richtige Berechtigungen, SELinux-Kontext, firewalld

Auf RHEL 10 gibt es zwei zusätzliche Stolpersteine, die bei anderen Distros nicht existieren:

• SELinux prüft Dateikontexte – restorecon -R ~/.ssh/ behebt Probleme
• firewalld muss SSH explizit erlauben – standardmäßig aktiv, aber prüfen

Mit ~/.ssh/config und SSH-Agent (auf Fedora über GNOME Keyring) wird das tägliche Arbeiten komfortabel: ein Befehl, keine Passwort-Tipperei, volle Sicherheit.