Passwortloses SSH einrichten im Homelab – NetBird & SSO als moderne Authentifizierung 2026

VonContentKalle

Wer im Homelab mehrere Server verwaltet, kennt das Problem: SSH-Keys auf jedem Client, Passwörter in Passwortmanagern, und trotzdem immer wieder das ungute Gefühl, ob der Zugang wirklich sicher ist. Passwortloses SSH einrichten mit Single Sign-On (SSO) ist die Antwort der modernen IT-Welt darauf – und mit NetBird im Homelab gelingt das überraschend einfach. In diesem Tutorial zeigen wir, wie ihr SSH-Zugriff über euren Identity Provider (IdP) absichert, ohne Port 22 ins Internet zu exponieren.

Warum passwortloses SSH? Das Problem mit klassischen SSH-Keys

Traditionelles SSH setzt auf zwei Ansätze: Passwort-Authentifizierung (unsicher, brute-force-anfällig) oder SSH-Public-Key-Authentifizierung. Letzteres gilt lange als Best Practice – aber auch hier lauern Probleme:

  • Key-Management-Chaos: Jeder Client braucht den richtigen Key, jeder Server muss die richtigen authorized_keys kennen.
  • Kein zentrales Offboarding: Verlässt ein Nutzer das Team (oder geht ein Gerät verloren), müssen Keys auf jedem Server einzeln gelöscht werden.
  • Keine Sitzungskontext-Informationen: SSH-Keys sagen nichts darüber aus, wer sich einloggt – nur welcher Key verwendet wird.
  • Port 22 offen: Auch mit Key-Auth bedeutet ein öffentlich erreichbarer SSH-Port ein ständiges Angriffsziel.

Die Lösung: SSH SSO Homelab-Setup mit identitätsbewusstem Zugang – kein offener Port, keine lokalen Keys, sondern euer IdP als einzige Quelle der Wahrheit.

NetBird: Zero-Trust-Netzwerk mit integriertem Identity-Aware SSH

NetBird ist ein Open-Source WireGuard-basiertes Overlay-Netzwerk mit integrierter SSO-Unterstützung. Seit Version 0.60.0 bietet NetBird einen vollständig überarbeiteten SSH-Stack, der native OpenSSH-Unterstützung mit Identity-Aware Authentication kombiniert. Das bedeutet:

  • Authentifizierung über euren Identity Provider (IdP) via OIDC/JWT
  • Kein Port 22 im Internet exponiert – der gesamte Zugriff läuft über das private NetBird-Overlay-Netz
  • Granulare Access-Policies: Welcher Nutzer darf auf welchen Server mit welchem lokalen OS-User?
  • Transparente OpenSSH-Integration – gewohnte ssh-Befehle funktionieren weiterhin

Unterstützte Identity Provider

NetBird arbeitet out-of-the-box mit den gängigsten IdPs zusammen:

  • Google Workspace
  • Microsoft Entra ID (ehemals Azure AD)
  • Okta
  • Authentik – der Favorit in der Homelab-Community (selbst gehostet!)
  • Keycloak – ebenfalls selbst hostbar, sehr mächtig
  • Alle weiteren OIDC-kompatiblen IdPs

Für das Homelab empfehlen wir Authentik oder Keycloak als selbst gehosteten IdP – kein Cloud-Zwang, volle Kontrolle.

Schritt-für-Schritt: Passwortloses SSH einrichten mit NetBird

Voraussetzungen

  • NetBird-Account (kostenloser Plan reicht für Homelab)
  • NetBird-Agent auf allen Servern und Clients installiert
  • Ein laufender IdP (z.B. Authentik auf eurem Proxmox/Docker-Host)
  • Linux-Server als SSH-Ziel (Ubuntu 22.04/24.04 empfohlen)

1. NetBird auf allen Geräten installieren

Auf jedem Server und Client installiert ihr den NetBird-Agent. Unter Linux:

curl -fsSL https://pkgs.netbird.io/install.sh | sh
sudo netbird up

Beim ersten Start öffnet sich ein Browser-Fenster zur SSO-Anmeldung über euren IdP. Nach der Authentifizierung ist das Gerät im NetBird-Netz registriert und bekommt eine feste private IP (z.B. 100.x.x.x).

2. SSH-Funktion in NetBird aktivieren

Den NetBird SSH-Server aktiviert ihr beim Start des NetBird-Agents auf dem Zielserver mit folgendem Befehl:

sudo netbird up --allow-server-ssh

Alternativ könnt ihr den SSH-Server auch über die NetBird Tray-App aktivieren: Tray-App → Settings → „Allow SSH“ (pro Gerät). NetBird installiert automatisch eine Drop-in-Konfigurationsdatei für den OpenSSH-Client, die JWT-Authentifizierung transparent handhabt – ihr müsst nichts manuell konfigurieren.

SSH-Zugriffsregeln werden im Dashboard unter Access Control → Policies verwaltet (TCP Port 22 für die gewünschten Gruppen freigeben).

3. Access Policy erstellen

Im NetBird Dashboard unter Access Control → Policies definiert ihr, wer wohin SSH-Zugriff bekommt:

  • Source: Eure Nutzergruppe (z.B. „homelab-admins“)
  • Destination: Eure Server-Gruppe (z.B. „homelab-servers“)
  • Protocol: TCP Port 22
  • OS User Mapping: Welcher IdP-User darf sich als welcher lokaler User einloggen (z.B. tim@yourdomain.com → ubuntu)

4. SSH-Verbindung aufbauen

Ab jetzt genügt ein normaler SSH-Befehl. NetBird kümmert sich automatisch um die JWT-Authentifizierung im Hintergrund:

ssh ubuntu@100.64.x.x

NetBird holt sich einen JWT-Token von eurem IdP, der SSH-Server validiert ihn gegen den JWKS-Endpoint – und ihr seid drin. Kein Passwort, kein Key-Management, kein offener Port im Internet.

5. Authentik als IdP für NetBird konfigurieren

Authentik ist in der Homelab-Community besonders beliebt, da es vollständig selbst gehostet werden kann und eine übersichtliche Web-UI mitbringt. So richtet ihr Authentik als OIDC-Provider für NetBird ein:

In Authentik:

  1. Navigiert zu Applications → Providers und erstellt einen neuen OAuth2/OIDC Provider.
  2. Setzt den Redirect URI auf: https://app.netbird.io/auth (für NetBird Cloud) oder eure selbst gehostete NetBird-Dashboard-URL.
  3. Notiert Client ID und Client Secret – diese braucht ihr gleich.
  4. Erstellt eine neue Application in Authentik, die diesen Provider verwendet, und weist die gewünschten Nutzergruppen zu.

In NetBird:

  1. Öffnet Settings → Identity Provider und wählt Custom OIDC.
  2. Tragt Client ID, Client Secret und die Authentik-Issuer-URL ein (z.B. https://authentik.yourdomain.com/application/o/netbird/).
  3. Speichert die Einstellungen – bestehende Verbindungen werden beim nächsten Token-Refresh automatisch aktualisiert.

Ab sofort authentifizieren sich alle Nutzer über Authentik, inklusive aller konfigurierten MFA-Methoden und Zugriffsregeln.

Bonus: Raspberry Pi als NetBird Routing Peer

Ihr könnt einen einfachen Raspberry Pi als Routing Peer einsetzen, um das gesamte Homelab-Subnetz über NetBird zugänglich zu machen – auch Geräte, auf denen kein NetBird-Agent läuft (z.B. ältere NAS-Systeme, Netzwerkswitches, Router).

Zunächst müsst ihr IP-Forwarding auf dem Raspberry Pi dauerhaft aktivieren, damit er als Router fungieren kann:

# IP-Forwarding sofort aktivieren
sudo sysctl -w net.ipv4.ip_forward=1

# Dauerhaft in /etc/sysctl.conf eintragen
echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.conf

Anschließend konfiguriert ihr die Route im NetBird Web Dashboard (CLI-Befehle für Routing-Konfiguration existieren nicht – das geschieht ausschließlich über das Dashboard):

  1. Navigiert zu Network Routes und klickt auf „Add Route“.
  2. Tragt als Network euer Heimnetz ein (z.B. 192.168.1.0/24).
  3. Wählt den Raspberry Pi als Routing Peer aus.
  4. Definiert die berechtigten Gruppen, die über diese Route erreichbar sind.
  5. Speichert die Route – sie wird automatisch auf alle verbundenen Peers verteilt.

Damit wird der Raspberry Pi zum Gateway für euer gesamtes Heimnetz – sicher hinter WireGuard, authentifiziert über SSO. Alle Geräte im Subnetz 192.168.1.0/24 sind jetzt über die privaten NetBird-IPs erreichbar, ohne dass auf jedem Gerät ein Agent installiert sein muss. Achtet darauf, dass der Raspberry Pi genug Netzwerkdurchsatz hat – für ein normales Homelab reicht ein Pi 4 mit Gigabit-Ethernet problemlos.

Vergleich: Klassische SSH-Keys vs. NetBird Identity-Aware SSH

Kriterium SSH-Keys (klassisch) NetBird + SSO
Authentifizierung Lokaler Private Key IdP (OIDC/JWT)
Offboarding Manuell auf jedem Server Zentral im IdP
Port 22 öffentlich Meist ja Nein
MFA-Unterstützung Nein (nur Key) Ja (via IdP)
Audit-Log Eingeschränkt Vollständig (Nutzeridentität)
Setup-Aufwand Gering (initial) Mittel (einmalig)

Fehlerbehebung: Typische Probleme und Lösungen

Beim ersten Einrichten können einige häufige Probleme auftreten. Hier die wichtigsten Troubleshooting-Tipps:

NetBird-Peer ist nicht sichtbar

Wenn sich zwei Peers nicht gegenseitig sehen, prüft zunächst den Verbindungsstatus:

sudo netbird status

Häufige Ursachen: Der NetBird-Agent ist nicht aktiv (sudo systemctl restart netbird), oder eine Firewall blockiert UDP-Port 51820 (WireGuard). Prüft außerdem, ob beide Peers derselben NetBird-Organisation zugeordnet sind und ob die Access Policy greift.

JWT-Token-Validierungsfehler

Erscheint beim SSH-Verbindungsaufbau ein JWT validation failed-Fehler, liegt das meist an einer abgelaufenen Session oder einem falsch konfigurierten JWKS-Endpoint. Überprüft die Uhrzeitsynchronisierung auf Server und Client (NTP), da JWT-Tokens zeitbasiert validiert werden:

sudo timedatectl status
sudo ntpdate -u pool.ntp.org

Konflikte mit firewalld oder ufw

Wenn der Routing-Peer nicht funktioniert, blockiert möglicherweise firewalld oder ufw den Forwarding-Traffic. Unter Ubuntu mit ufw:

sudo ufw allow in on netbird0
sudo ufw allow forward

Unter RHEL/CentOS mit firewalld fügt ihr die NetBird-Schnittstelle zur vertrauenswürdigen Zone hinzu:

sudo firewall-cmd --zone=trusted --add-interface=netbird0 --permanent
sudo firewall-cmd --reload

Sicherheits-Best-Practices für NetBird im Homelab

Damit euer Setup langfristig sicher bleibt, empfehlen wir folgende Best Practices:

  • Nutzergruppen sauber segmentieren: Nicht alle Homelab-Nutzer brauchen Zugriff auf alle Server. Erstellt separate NetBird-Gruppen für Admins, Entwickler und ggf. Gäste.
  • NetBird-Logs regelmäßig auswerten: Das Activity-Log im Dashboard zeigt, wer wann auf welchen Peer zugegriffen hat – ideal für Compliance und Incident Response.
  • OIDC-Token-Lifetime begrenzen: In Authentik oder Keycloak die Access-Token-Lifetime auf 15–60 Minuten setzen, damit kompromittierte Tokens schnell ungültig werden.
  • MFA erzwingen: Im IdP für alle Nutzer mit SSH-Zugriff mehrstufige Authentifizierung (TOTP oder WebAuthn) als Pflicht konfigurieren.

Fazit: SSH im Homelab neu gedacht

Passwortloses SSH einrichten mit NetBird und SSO ist kein übertriebener Enterprise-Overhead – es ist der logische nächste Schritt für jedes ernst genommene Homelab. Der initiale Aufwand ist überschaubar, besonders wenn ihr ohnehin schon Authentik oder Keycloak betreibt. Was ihr dafür bekommt: zentrales Identity-Management, MFA für alle SSH-Verbindungen, kein offener Port im Internet, und vollständige Audit-Logs darüber, wer wann auf welchem Server war.

Habt ihr NetBird bereits im Einsatz oder setzt ihr auf eine andere Zero-Trust-Lösung? Schreibt es in die Kommentare – besonders interessiert uns, welchen IdP ihr im Homelab verwendet!

Ähnliche Beiträge