Why I Stopped Trusting SSH Key Files

20 Jun, 2026

Earlier today I added my iPhone as an authorized device to a server, and the way I did it is worth writing about — because it's quietly one of the best security upgrades you can make with zero ongoing effort. The key I used never touched a disk, can't be copied off my phone, and only works after Face ID says so. Here's why that matters, and why these keys beat almost everything else people use to log into servers.

First, the threat we're actually defending against

While setting this up, I tailed the server's auth log. In a single 90-second window, random bots from five different countries tried to brute-force the root login. This is normal. Every public-facing server on the internet is under constant automated attack. The only reason mine shrugs it off is that password authentication is disabled entirely — there's nothing to guess. That's the baseline: keys, not passwords. But not all keys are equal.

The problem with traditional SSH key files

A normal SSH key (~/.ssh/id_ed25519) is just a file sitting on your laptop. It's wonderful compared to a password, but it has a soft underbelly:

• It's exportable. Anyone who reads that file — malware, a backup leak, a borrowed laptop, a cloud-sync mishap — now has your private key forever.
• It's often unprotected. Plenty of people skip the passphrase, or use a weak one, because typing it is annoying.
• It doesn't prove possession. A copied key works from anywhere, silently. There's no "is the real owner here right now?" check.

The private key is the crown jewel, and we leave it lying on the floor in a text file.

Secure Enclave keys fix this at the hardware level

The key I generated lives in the Secure Enclave — a dedicated security chip on the iPhone that's isolated from the main processor and even from iOS itself. Here's what makes it different:

• The private key is never exportable. It's generated inside the chip and physically cannot leave. Signing happens in the enclave; the key material never appears in memory, in a backup, or anywhere an attacker could grab it. Stealing it would mean physically de-capping a chip.
• Every use requires biometrics. No connection happens without Face ID or Touch ID. That adds a second, unforgeable factor — something you are — on top of something you have (the phone). A thief with my unlocked phone still can't reach the server without my face.
• It's bound to one device. Because the key can't be copied, each device gets its own. Lose the phone? Delete one line in authorized_keys and that device is revoked — every other device keeps working.

The honest trade-off

There's one nuance worth being straight about: the Secure Enclave only supports ECDSA on the NIST P-256 curve, not Ed25519. On pure cryptographic elegance, Ed25519 wins (no risky nonce generation, faster, simpler). But that Ed25519 key still lives in a file. For real-world threats — stolen laptops, leaked backups, malware — a P-256 key locked in tamper-resistant hardware and gated by your face beats a "better" algorithm sitting unprotected on disk. Hardware custody trumps theoretical curve strength for almost everyone.

The bottom line

Passwords are guessable. Key files are stealable. A Secure Enclave key is neither: non-exportable, biometric-gated, per-device, and instantly revocable. The setup took about two minutes and the private key has never existed anywhere but a chip in my pocket. That's the kind of security that costs nothing and asks nothing of you afterward — the best kind.