Chapter 10 · Operate

Threat model & key custody

Security advice given without a threat model is just superstition with a command line. This chapter states plainly who you are defending against, which controls actually stop them, and — the part usually left out — what this design does not protect you from.

Who is actually attacking you

Layers, and what each one actually stops

The value of defence in depth is that each layer fails differently. A misconfigured sshd_config does not matter if the packet never arrives; a tailnet ACL mistake does not matter if the key is not in authorized_keys.

Who is knocking Internet scanner Café Wi-Fi A bad ACL edit Stolen phone You, with your key

◀ ▶Play ▶

0 1 2 3 4 5

# a botnet, mid-sweep
masscan 0.0.0.0/0 -p22 --rate 20000 — you are one of forty million

$ arp -a
192.168.1.44 — your MacBook, same hotel segment, no tailnet needed

# the ACL edit you made at 11pm
"dst": ["*:22"] — the star is doing a lot of work

# the phone is in someone else's pocket
still a tailnet member · screen locked

$ ssh macbook
the ordinary case — every ring is built to allow it

$ nmap -Pn -p22 203.0.113.10
22/tcp filtered ssh — nothing to talk to

# ring 1 never sees this packet
it is addressed to the Wi-Fi interface, not the tailnet

$ tailscale status
100.64.9.12 unknown-laptop active — and now permitted to :22

$ tailscale status
100.83.14.9 iphone iOS active — granted to :22

$ nc -z -w 3 192.168.1.44 22
nc: connect to 192.168.1.44 port 22 failed: Connection refused

$ nc -z -w 3 100.117.202.65 22
Connection to 100.117.202.65 port 22 succeeded!

# not run — ring 1 already ended it
there was never a socket to reach

$ ssh root@100.117.202.65
Permission denied (publickey). no root, no passwords, not on AllowUsers

$ ssh -v macbook
debug1: Authentications that can continue: publickey

# not run — the packet never got this far
sshd never saw a byte of it

# the enclave declines
Face ID or passcode required — no signature, no login

$ ssh -v macbook
debug1: Server accepts key … Authenticated to macbook

# not run — no key was ever offered here
an outer ring answered first

$ dseditgroup -o checkmember -m you com.apple.access_ssh
yes — you land in a shell

# not run — an outer ring already stopped this
the shell was never in reach

1. An internet scannerConstant, indiscriminate, and arriving within minutes of any VPS getting an address. It has never heard of you; it is trying everyone. This is the most common adversary by several orders of magnitude, and the one the outermost ring exists for.
2. A neighbour on the café Wi-FiYou joined a hotel network and so did they. They can reach your machine's local address directly — no tailnet, no coordination server, nothing for ring 1 to have an opinion about. This is why ring 1 alone is not enough.
3. A bad ACL editYou widened one rule late at night and a device you never meant to allow now matches it. Nothing is broken yet and nothing warns you. Ring 1 is the ring that eventually breaks — the question is what happens next.
4. Your phone, in someone else's pocketIt is still a member of the tailnet, because you have not revoked it yet. It holds an SSH key that every one of your machines trusts. And it is locked. Watch how far it gets.
5. You, with your keyThe one case every ring is built to let through. Worth stepping once, because it is the only run where you see all five rings answer yes — and it shows the cost of the design is a single ssh.
6. 1 · Stopped at the tailnet ACLThere is no port to find. sshd is bound to the tailnet address and nothing else, so the scan hits a filtered port and moves on. This is the single highest-value control in the guide — it removes an entire adversary class instead of hardening against it.
7. 1 · Bypassed, not defeatedThe rings are not literally concentric for every attacker. This packet is addressed to your Wi-Fi interface, so the tailnet ACL is never consulted at all. A control that is not on the path cannot help you — which is the whole argument for the ring below.
8. 1 · Passed — and it should not haveThe grant was too broad, so a device you never intended to allow now reaches port 22. Ring 1 has failed silently, exactly the way misconfiguration always does. If it were your only layer, this would already be an incident.
9. 1 · On the tailnet, port grantedThe device is a member and the ACL permits it to reach port 22, so the packet is delivered. Correct in both cases — the phone is yours, and you have not revoked it yet.
10. 2 · Stopped at the bind addresssshd listens on the 100.x address only, so on the hotel segment there is simply nothing to answer. Ring 1 never applied here; ring 2 did the work alone. Default-deny inbound means your laptop offers that network nothing.
11. 2 · Reached the right interfaceThe packet arrived over the tailnet interface, which is precisely the one sshd is bound to. Nothing here looks suspicious yet — a device that slipped past ring 1 is indistinguishable from a legitimate one at this layer.
12. 2 · Not runRing 1 already ended it. Nothing inside was ever tested, which is the point: a control that stops traffic before it arrives makes every control behind it irrelevant to that attacker.
13. 3 · The daemon says no — and this is the payoffPassword authentication is off, root login is off, and this account is not in AllowUsers. Ring 1 failed, and the result was an inconvenience rather than an incident. This is why you harden sshd even behind a private network.
14. 3 · Policy permits this loginKey authentication only, no root, and the account is on the allow list. The daemon has no objection to this attempt — it is a legitimate user account presenting itself the approved way.
15. 3 · Not runThe packet never got this far, so sshd_config played no part in the outcome. Worth remembering when you are tempted to debug a connection problem by editing it.
16. 4 · The enclave will not signThe key is hardware-bound and every use is gated by Face ID or the passcode. A thief has the device, not the key — and cannot copy it out to try elsewhere. This is what makes losing a phone a chore rather than a crisis.
17. 4 · Your key signs the challengeThe private key never leaves the enclave; the enclave returns a signature over the session ID. Note the honest limit: if malware were running on your unlocked machine, it could ask for that same signature. Possession of the device is the boundary.
18. 4 · Not runNo key was ever offered here, because an outer ring answered first. Key custody is a strong layer, but it only gets a turn if the packet reaches it.
19. 5 · On the SSH access list, and into the shellPAM checks com.apple.access_ssh and lets you through. Five rings, five yeses, one shell. Each of them fails differently, which is the entire value of the arrangement — the failure of any one is survivable.
20. 5 · Not runAn outer ring already stopped this attempt, so the shell was never in reach. Switch the attacker above and watch where the run ends — no two of them stop at the same ring.

Where every key lives

Knowing this table cold is what makes an incident boring instead of frightening.

What goes wrong The device is lost Malware on the machine An unencrypted backup

◀ ▶Play ▶

0 1 2 3

1. Day to day, they are indistinguishableBoth keys log you in. The difference only shows up on the worst day of the year, which is exactly why it is worth understanding before then. The file key hands its bytes to whatever opens the file; the enclave hands back a signature and keeps the key.
2. 1 · The device is goneThe laptop leaves with the key file on its disk. FileVault protects that file while the machine is powered off — and only then; a sleeping machine has already derived the volume key. The phone leaves with its key too, but sealed in a coprocessor that has no read operation.
3. 1 · Something is running that should not beA bad dependency or a malicious extension. On the file side, one open() is the entire attack — no prompt, no trace. On the enclave side it cannot read the key, but here is the honest limit: it can ask the enclave to sign while you are unlocked. Hardware-bound is not the same as safe from a compromised endpoint.
4. 1 · A backup ran, unencryptedTime Machine to an unencrypted disk, a tar of your home directory, a sync tool with generous defaults. The file key is now inside that archive. The enclave key was never a file, so there was nothing for the backup to pick up.
5. 2 · What they end up holdingThe disk holds the key file, so you have to assume it becomes readable eventually — a stolen laptop is not a one-hour problem. The enclave holds the phone's key, and every use of it is gated by Face ID or the passcode. It cannot be copied off the chip at any price.
6. 2 · What they end up holdingOn the file side, the key itself: usable from any machine, at any time, and you cannot tell it happened. On the enclave side, no key at all — only access, bounded to that one device and to the time it stays unlocked. That bound is the difference between an incident and a permanent one.
7. 2 · What they end up holdingThe key file is in the archive, protected only by its passphrase — and a passphrase in someone else's hands brute-forces offline, patiently, without rate limits. The enclave key is simply not in there. Nothing to crack now, and nothing to crack in five years.
8. 3 · What it costs youFile key: rotate everywhere, promptly, on every host and service that trusts it — under time pressure, on a bad day. Enclave key: revoke the node in the admin console, then delete one authorized_keys line per host. Nothing else to rotate, because the key existed nowhere else.
9. 3 · What it costs youFile key: rotate everywhere, then audit what was done with it in the meantime. Enclave key: revoke the node and audit the same window — but you do not rotate keys on your other machines, because this one never left the phone. A compromised endpoint is still a compromised endpoint; the blast radius is what changes.
10. 3 · What it costs youFile key: rotate everywhere, because you do not know who read that archive or how many copies of it exist. Enclave key: nothing at all. The backup was always safe to store, and that is a property you get for free rather than by remembering to be careful.

Blast radius

For each thing that could go wrong, what does the attacker actually get?

What this design does not protect against

Stated plainly, because a threat model that claims to cover everything is not a threat model:

• A compromised endpoint you are actively using. Malware on your unlocked Mac acts as you. No network design fixes this.
• Malicious code you run yourself. A backdoored dependency executes with your privileges. This is the most probable serious compromise for most developers, and nothing in this guide addresses it.
• Coercion. Encryption yields to a court order or a threat.
• Your cloud provider. They control the hypervisor. Disk encryption on a VPS protects against decommissioned-disk recovery, not against the host.
• Metadata. Your ISP cannot read WireGuard traffic but sees that you connect and how much.

Incident response

Phone lost or stolen

1. Tailscale admin console → remove the device. It loses network access immediately; this is the fastest and broadest action, so do it first.
2. Find My → Mark as Lost, and Erase if you are confident it is gone.
3. Remove its line from ~/.ssh/authorized_keys on every machine.
4. No further rotation needed — the Secure Enclave key never existed anywhere else.

A machine's SSH key may have leaked

1. Remove the public key from every authorized_keys immediately. Revocation first, replacement second.
2. Generate a fresh key on that device and distribute the new public half.
3. Check ~/.ssh/authorized_keys on every host for entries you do not recognise — adding a key is the classic persistence move.
4. Review authentication logs for the fingerprints that actually logged in: grep 'Accepted publickey' /var/log/auth.log. This is what LogLevel VERBOSE was for.

A server may be compromised

1. Isolate it: sudo tailscale down, and remove the node from the tailnet.
2. Do not trust anything it tells you. A rootkit edits the logs and the tools that read them.
3. Snapshot the disk for later analysis if it matters.
4. Rebuild rather than clean. Restore data, not binaries. Regenerate host keys; clients will warn, and that warning is correct.
5. Rotate every credential that machine held.

Review periodically

• Every entry in every authorized_keys is one you recognise and still want.
• Tailnet device list contains no machines you have retired.
• Key expiry is on where appropriate; you know where you disabled it and why.
• Tailnet lock is enabled and recovery keys are reachable from another device.
• FileVault and LUKS recovery keys are stored off the machines they unlock.
• ACL policy still reflects reality after any new device joined.
• Auth logs reviewed for unfamiliar key fingerprints.

The commands in this guide change firewall and login settings, and can lock you out of a machine. Practise on something disposable first. Everything here is provided as is, with no warranty — you accept the risk of running it. Read the disclaimer.