SSH keys on your phone: generate, import, and use them without leaking the private key

#ssh #security #mobile #devops

Password SSH from a phone is a bad habit waiting to bite you: it's phishable, brute-forceable, and painful to type on a touch keyboard. Keys fix all three — but "just use keys" glosses over the part that actually trips people up on mobile: where the private key lives, and how it gets onto the phone without ever leaking.

Here's the practical version.

The one rule: the private key never travels as plaintext

A keypair is two halves. The public key is safe to hand out — you copy it to every server. The private key is the secret; if it leaks, anyone can log in as you. The whole game is keeping the private half from ever sitting somewhere insecure — a chat message, an email attachment, a synced Notes app, a screenshot.

That leads to two clean approaches on a phone. Pick one; don't mix.

Approach A — generate the key on the phone (best)

The private key is created on the device and never leaves it.

Generate a new Ed25519 key (ssh-keygen -t ed25519 is the desktop equivalent; a good mobile client does this in-app). Ed25519 over RSA: shorter, faster, modern.
Protect it with a passphrase. On a phone this is the difference between "lost phone = lost servers" and "lost phone = shrug."
Copy the public key to each server's ~/.ssh/authorized_keys (paste it, or use ssh-copy-id from a machine that already has access).
Store the private key in the phone's secure enclave / Keychain, not a plain file. A well-built client keeps it there and gates use behind Face ID / Touch ID.

Now the secret was born on the device, is encrypted at rest, and requires biometrics to use. That's the setup you want.

Approach B — import an existing key (only if you must)

If you already have a key on your laptop and genuinely need the same one on the phone, move it out of band and encrypted, never through a chat app or email:

Prefer an encrypted transfer your client supports (some import via QR from a paired desktop, or over an encrypted local channel).
If you must move a file, make sure it's a passphrase-protected private key, delete the intermediate copy afterward, and rotate it later if you're unsure where it went.
Honestly, generating a new per-device key (Approach A) and adding its public half to your servers is usually less risky than shuttling one private key around.

Two mistakes that quietly undo all of this

A key with no passphrase, synced to the cloud. iCloud/Google backups of an unprotected private key mean your servers are one account compromise away. Passphrase + secure-enclave storage avoids it.
Reusing one key everywhere with no way to revoke. Use a per-device key (laptop, phone, tablet each their own). Then losing one device = remove one public key line from authorized_keys, not re-key everything.

Lock the door behind you

Once keys work, turn passwords off on the server so a stolen/weak password can't bypass all this:

# /etc/ssh/sshd_config
PasswordAuthentication no
PubkeyAuthentication yes

Then sudo systemctl reload sshd. Test a new key-based login in a second session before closing your current one.

The mobile-specific bit

Everything above is standard SSH hygiene — the phone twist is storage and unlock. On a phone your private key should live in the secure enclave and unlock with biometrics, so a shoulder-surfer or a grabbed-and-unlocked phone still can't export it. That's a core thing I build into TermAI (keys in the Keychain, Face ID to use them, generate-on-device by default), but the principle holds for any client you pick: generate on device, passphrase-protect, store in the enclave, one key per device.

Do that and SSH from a phone stops being the scary option and becomes the safe one.

How do you handle keys across devices — one key synced, or a separate key per device with public keys fanned out?

DEV Community