termalEin NAS oder ein kleiner Heim-Server ist der beste Grund, den die meisten haben, um SSH zu lernen: Es ist dein Speicher, deine Backups, deine Medien, vielleicht eine Handvoll Container – und du willst es vom Sofa, von der Arbeit, vom Handy aus erreichen. SSH ist der Weg, das ohne angeschlossenen Bildschirm an der Kiste zu tun – von einem Laptop oder von einem SSH-Client für iPhone oder iPad, wenn du nicht am Schreibtisch bist. Die Falle ist der Sprung von „geht in meinem eigenen Netz“ zu „von überall erreichbar“, wo die falsche Abkürzung dein Homelab ins offene Internet stellt. Hier der sichere Weg, von Anfang bis Ende.
Schritt eins: im eigenen Netz erreichen
Bevor du etwas Cleveres machst, bestätige, dass SSH funktioniert, während du zu Hause im selben WLAN oder LAN bist.
Schalte SSH ein. Die meisten NAS-Geräte kommen mit ausgeschaltetem SSH. Bei einer Synology: Terminal & SNMP → Enable SSH service; bei einer QNAP: Control Panel → Telnet/SSH; bei TrueNAS: Services → SSH. Ein schlichter Linux-Heim-Server betreibt meist schon sshd. Welche Kiste auch immer, es gibt einen Schalter – leg ihn um und merke dir den Port (standardmäßig 22, manchmal verschoben).
Finde seine Adresse. Die Client-Liste deines Routers zeigt sie, oder die Admin-Seite des NAS zeigt seine LAN-IP (etwas wie 192.168.1.50). Dann:
ssh admin@192.168.1.50Der Benutzername ist das Konto, mit dem du dich am NAS anmeldest – admin bei vielen Geräten, dein eigener Benutzer auf einer Linux-Kiste, manchmal root. Wenn es sich verbindet und dich an einer Shell absetzt, ist der schwere Teil erledigt; alles Weitere ist nur, wie du dieselbe Shell von außerhalb des Hauses erreichst.
Schritt zwei: von außen erreichen – ohne Port 22 zu öffnen
Der naheliegende Schritt ist, Port 22 auf deinem Router ans NAS weiterzuleiten. Tu’s nicht. Ein öffentlich erreichbarer SSH-Port wird von Scannern binnen Minuten gefunden – deine Logs füllen sich ab der ersten Sekunde mit Connection reset by peer und Tausenden Login-Versuchen. Vier bessere Wege, die deinen Router nie öffnen, grob in der Reihenfolge, wie sehr ich sie empfehlen würde (das Playbook SSH hinter NAT (auf Englisch) geht bei jedem tiefer):
Ein Overlay-Netzwerk (die einfache, sichere Standardwahl). Tools wie Tailscale oder ein WireGuard-Setup stellen deine Geräte in ein privates Netz, das nur sie sehen. Dein Laptop und dein NAS bekommen stabile private Adressen, und du machst ssh admin@100.x.y.z von überall, als wärst du zu Hause – die Kiste ist dem öffentlichen Internet nie ausgesetzt. Für die meisten Homelabs ist das die ganze Antwort.
Ein verwalteter, nur ausgehender Connector. Wenn du lieber kein Mesh oder VPS selbst aufsetzt, ist Termalins Connector ein kleiner Agent, den du mit einer Zeile auf dem NAS installierst. Er wählt sich nach draußen zu Termalin – kein eingehender Port auf deinem Router – und du erreichst die Shell der Kiste aus der App oder dem Browser, authentifiziert mit einem kurzlebigen Zertifikat statt einem Schlüssel, der auf dem NAS liegt. Dasselbe Prinzip kein-eingehender-Port wie beim Overlay-Netzwerk, ohne das Relay selbst zu betreiben.
Ein Reverse-Tunnel hinaus zu einem günstigen VPS. Wenn du schon einen kleinen Server mietest, kann das NAS sich nach draußen zu ihm wählen und seinen SSH-Port zurückleiten – du erreichst das NAS dann, indem du dich mit dem VPS verbindest. Auf deinem Heimrouter wird nie etwas Eingehendes geöffnet. Das ist das Reverse-Tunnel-Muster (auf Englisch), der handgemachte Vetter des obigen Connectors, und das richtige Werkzeug, wenn ein Overlay-Netzwerk keine Option ist.
Dynamisches DNS + Portweiterleitung (der alte Weg – nur wenn es sein muss). Wenn du darauf bestehst, SSH freizulegen, dann wenigstens: weg von Port 22, nur Schlüssel erlauben (PasswordAuthentication no) und fail2ban laufen lassen. Ein dynamischer DNS-Hostname kümmert sich um deine wechselnde Heim-IP. Das funktioniert, aber du pflegst jetzt eine zum Internet gerichtete Angriffsfläche für eine Kiste voller persönlicher Daten – das Overlay-Netzwerk gibt es genau dafür, dass du das nicht musst.
Schritt drei: Schlüssel, keine Passwörter
Welchen Weg du auch wählst, melde dich mit einem Schlüssel an, nicht mit einem Passwort. Erzeug einen modernen – siehe Ed25519 vs. RSA (auf Englisch) für die Dreißig-Sekunden-Fassung –, leg seine öffentliche Hälfte in die authorized_keys des NAS-Benutzers, und sobald das klappt, schalte den Passwort-Login ab. Ein Schlüssel, den du pro Gerät widerrufen kannst, schlägt ein Passwort, das sich jedes Konto teilt, und er ist es, der die obige Haltung „nichts freilegen, nur Schlüssel“ erst tragfähig macht.
Einen KI-Agenten beim Betrieb der Kiste helfen lassen
Hierhin steuern Homelabs 2026: Statt dich selbst per SSH einzuloggen, um zu prüfen, warum ein Container gestorben ist oder eine Disk vollgelaufen ist, bittest du einen Assistenten – Claude Code, Cursor, ein lokales Modell –, nachzusehen. Das ist wirklich nützlich. Es ist auch genau der Punkt, an dem Leute den Fehler machen, den sie bei einem Fremden nie machen würden: dem Agenten eine Shell auf der Kiste zu geben, die ihre Backups hält.
Das Zögern ist der richtige Instinkt. Ein Agent mit deinem NAS-Schlüssel kann alles, was du kannst, und er kann durch eine vergiftete Log-Zeile oder einen bösartigen Dateinamen, den er unterwegs liest, zu Dingen überredet werden – der Blast Radius (auf Englisch) ist die ganze Kiste, nicht die eine Aufgabe, um die du gebeten hast. Die Lösung ist nicht, die Idee aufzugeben; sie ist, zu ändern, was der Agent bekommt. Statt des Schlüssels und einer blanken Shell sollte der Agent durch etwas gehen, das:
- den Schlüssel für ihn hält – der Agent verbindet sich, sieht oder speichert die Zugangsdaten aber nie, ein geleakter Agentenkontext ist also kein geleakter NAS-Login;
- begrenzt, was er ausführen kann – eine Richtlinie pro Host, die sagt, dass dieser Agent diese Befehle auf dem NAS ausführen darf und sonst nichts (Logs und Plattenbelegung lesen, ja;
rm -rf, nein); - sichtbar bleibt – du siehst der Sitzung live zu und sie wird in ein Audit-Log geschrieben, sodass „der Agent hat etwas Platz freigeräumt“ etwas ist, das du tatsächlich prüfen kannst und nicht glauben musst.
Das ist dasselbe Prinzip wie der Reverse-Tunnel und der Nur-Schlüssel-Login oben – nicht mehr freilegen, als die Aufgabe braucht (auf Englisch) – angewandt auf den Agenten statt auf das Internet.
Wo Termalin hineinpasst
Termalin ist ein plattformübergreifender SSH-Client – Windows, macOS und Linux auf dem Desktop, dazu eine native App für iPhone und iPad und ein Browser-Client – gebaut für genau diese Art von Problem. Es kümmert sich um die Tunnel (auf Englisch), die eine Heim-Kiste erreichen, ohne deinen Router zu öffnen, hält Benutzer, Schlüssel und Port jedes Hosts zusammen, sodass ein NAS ein Klick ist und keine gemerkte IP, und zeigt Disk, Speicher und Last der Maschine live in der Statusleiste – sodass „läuft die Kiste überhaupt, und ist die Disk voll?“ beantwortet ist, bevor du einen Befehl tippst.
Und wenn ein Agent helfen soll, verbindet er sich über Termalins integrierten MCP-Server: Der Agent arbeitet über deinen SSH-Zugriff, ohne je deinen Schlüssel zu halten, begrenzt durch eine Befehlsrichtlinie pro Host (auf Englisch), die du festlegst, gespiegelt in einem Watch Grid live und protokolliert. Das Homelab bekommt einen fähigen Assistenten; der Assistent bekommt nie die Schlüssel dazu. Der Free-Tarif hat kein Host-Limit – hol es dir und richte es auf dein NAS.
Termalin ist ein kostenloser, plattformübergreifender SSH-Client mit integriertem MCP-Server – sicherer SSH-Zugriff für dich und für die KI-Agenten, die du helfen lässt. Lade es herunter oder lies das Sicherheitsmodell.