Why I Stopped Trusting SSH Key Files – Igor's Techno Club
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<br>did it is worth writing about — because it's quietly one of the best security<br>upgrades you can make with zero ongoing effort. The key I used never touched a<br>disk, can't be copied off my phone, and only works after Face ID says so. Here's<br>why that matters, and why these keys beat almost everything else people use to log<br>into servers.
First, the threat we're actually defending against<br>While setting this up, I tailed the server's auth log. In a single 90-second<br>window, random bots from five different countries tried to brute-force the root<br>login. This is normal. Every public-facing server on the internet is under<br>constant automated attack. The only reason mine shrugs it off is that password<br>authentication is disabled entirely — there's nothing to guess. That's the<br>baseline: keys, not passwords. But not all keys are equal.
The problem with traditional SSH key files<br>A normal SSH key (~/.ssh/id_ed25519) is just a file sitting on your laptop. It's<br>wonderful compared to a password, but it has a soft underbelly:
It's exportable. Anyone who reads that file — malware, a backup leak, a<br>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<br>one, because typing it is annoying.
It doesn't prove possession. A copied key works from anywhere, silently.<br>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<br>file.
Secure Enclave keys fix this at the hardware level<br>The key I generated lives in the Secure Enclave — a dedicated security chip on<br>the iPhone that's isolated from the main processor and even from iOS itself. Here's<br>what makes it different:
The private key is never exportable. It's generated inside the chip and<br>physically cannot leave. Signing happens in the enclave; the key material never<br>appears in memory, in a backup, or anywhere an attacker could grab it. Stealing<br>it would mean physically de-capping a chip.
Every use requires biometrics. No connection happens without Face ID or<br>Touch ID. That adds a second, unforgeable factor — something you are — on top<br>of something you have (the phone). A thief with my unlocked phone still can't<br>reach the server without my face.
It's bound to one device. Because the key can't be copied, each device gets<br>its own. Lose the phone? Delete one line in authorized_keys and that device is<br>revoked — every other device keeps working.
The honest trade-off<br>There's one nuance worth being straight about: the Secure Enclave only supports<br>ECDSA on the NIST P-256 curve, not Ed25519. On pure cryptographic elegance,<br>Ed25519 wins (no risky nonce generation, faster, simpler). But that Ed25519 key<br>still lives in a file. For real-world threats — stolen laptops, leaked backups,<br>malware — a P-256 key locked in tamper-resistant hardware and gated by your face<br>beats a "better" algorithm sitting unprotected on disk. Hardware custody trumps<br>theoretical curve strength for almost everyone.
The bottom line<br>Passwords are guessable. Key files are stealable. A Secure Enclave key is neither:<br>non-exportable, biometric-gated, per-device, and instantly revocable. The setup<br>took about two minutes and the private key has never existed anywhere but a chip in<br>my pocket. That's the kind of security that costs nothing and asks nothing of you<br>afterward — the best kind.