termalA NAS or a little home server is the best reason most people have to learn SSH: it’s your storage, your backups, your media, maybe a handful of containers — and you want to reach it from the couch, from work, from your phone. SSH is how you do that without a screen plugged into the box. The trap is the jump from “works on my own network” to “reachable from anywhere,” where the wrong shortcut puts your home lab on the open internet. Here’s the safe path, start to finish.
Step one: reach it on your own network
Before anything clever, confirm SSH works while you’re home on the same Wi-Fi or LAN.
Turn SSH on. Most NAS boxes ship with it off. On a Synology, Terminal & SNMP → Enable SSH service; on a QNAP, Control Panel → Telnet/SSH; on TrueNAS, Services → SSH. A plain Linux home server usually already runs sshd. Whatever the box, there’s a toggle — flip it, and note the port (22 by default, sometimes moved).
Find its address. Your router’s client list shows it, or the NAS admin page displays its LAN IP (something like 192.168.1.50). Then:
ssh [email protected]The username is whatever account you log into the NAS with — admin on many appliances, your own user on a Linux box, sometimes root. If it connects and drops you at a shell, the hard part is done; everything below is just how to reach this same shell from outside the house.
Step two: reaching it from outside — without exposing port 22
The obvious move is to forward port 22 on your router to the NAS. Don’t. A publicly reachable SSH port is found by scanners within minutes — your logs will fill with Connection reset by peer and thousands of login attempts from the moment it goes live. Three better ways, roughly in order of how much I’d recommend them:
An overlay network (the easy, safe default). Tools like Tailscale or a WireGuard setup put your devices on a private network that only they can see. Your laptop and your NAS get stable private addresses, and you ssh [email protected] from anywhere as if you were home — the box is never exposed to the public internet at all. For most home labs this is the whole answer.
A reverse tunnel out to a cheap VPS. If you already rent a small server, the NAS can dial out to it and forward its SSH port back — you then reach the NAS by connecting to the VPS. Nothing inbound is ever opened on your home router. This is the reverse-tunnel pattern, and it’s the right tool when an overlay network isn’t an option.
Dynamic DNS + port-forward (the old way — only if you must). If you insist on exposing SSH, at least: move it off port 22, allow keys only (PasswordAuthentication no), and run fail2ban. A dynamic-DNS hostname handles your changing home IP. This works, but you are now maintaining an internet-facing attack surface for a box full of your personal data — the overlay network exists precisely so you don’t have to.
Step three: keys, not passwords
Whichever route you pick, log in with a key, not a password. Generate a modern one — see Ed25519 vs RSA for the thirty-second version — put its public half in the NAS user’s authorized_keys, and once that works, turn password login off. A key you can revoke per device beats a password every account shares, and it’s what makes the “expose nothing, key-only” posture above actually hold.
Letting an AI agent help run the box
Here’s where home labs are heading in 2026: instead of SSHing in yourself to check why a container died or a disk filled up, you ask an assistant — Claude Code, Cursor, a local model — to look. That’s genuinely useful. It’s also exactly where people make the mistake they’d never make with a stranger: handing the agent a shell on the box that holds their backups.
The instinct is right to hesitate. An agent with your NAS key can do anything you can, and it can be talked into things by a poisoned log line or a malicious filename it reads along the way — the blast radius is the whole box, not the one task you asked for. The fix isn’t to give up on the idea; it’s to change what the agent gets. Instead of the key and a raw shell, the agent should go through something that:
- holds the key for it — the agent connects, but never sees or stores the credential, so a leaked agent context isn’t a leaked NAS login;
- limits what it can run — a per-host policy that says this agent may run these commands on the NAS and nothing else (read logs and disk usage, yes;
rm -rf, no); - stays visible — you watch the session live and it’s written to an audit log, so “the agent cleaned up some space” is a thing you can actually check, not take on faith.
This is the same principle as the reverse tunnel and the key-only login above — don’t expose more than the job needs — applied to the agent instead of the internet.
Where Termalin fits
Termalin is a cross-platform SSH client (Windows, macOS, Linux) built for exactly this shape of problem. It handles the tunnels that reach a home box without opening your router, keeps each host’s user, key and port together so a NAS is one click and not a remembered IP, and shows the machine’s disk, memory and load live in the status bar — so “is the box even up, and is the disk full?” is answered before you type a command.
And when you want an agent to help, it connects through Termalin’s built-in MCP server: the agent works over your SSH access without ever holding your key, bounded by a per-host command policy you set, mirrored in a live watch grid, and logged. The home lab gets a capable assistant; the assistant never gets the keys to it. The Free tier has no host limits — grab it and point it at your NAS.
Termalin is a free, cross-platform SSH client with a built-in MCP server — safe SSH access for you and for the AI agents you let help. Download it, or read the security model.