SSH access that doesn’t live forever.

Why SSH keys become a liability

An SSH key pair is a strong credential. The trouble is everything around it. A public key copied into authorized_keys grants access until someone removes it, and nothing in the file says who it belongs to, why it’s there or whether it’s still needed.

• No expiry. A key added for a two-week project is still valid two years later.
• No identity. The comment field is free text. Shared deploy keys and personal keys look the same.
• No central view. Access lives on each server. Answering “who can reach production?” means reading every authorized_keys file.
• Offboarding misses. Disabling someone’s SSO account doesn’t touch the key on their laptop or the copies on your servers.
• Private keys wander. Keys without hardware backing can be copied between laptops, backups and CI systems.

Four ways teams manage SSH access

Each approach fixes part of the problem. FIDO2-backed keys (the ed25519-sk and ecdsa-sk types added in OpenSSH 8.2) put the private key in hardware. SSH certificates, signed by a CA your servers trust, add expiry and identity. An access platform adds policy, device checks and a central record.

How to audit your SSH access today

You don’t need new tooling to find out where you stand. These steps work on most Linux servers running OpenSSH. Run them on a representative sample first, then script them across your fleet.

1. Find where keys are allowed

Check which files sshd reads, then find them:

sudo sshd -T | grep -i authorizedkeysfile
sudo find / -xdev \( -name authorized_keys -o -name authorized_keys2 \) 2>/dev/null

2. Fingerprint every key

ssh-keygen can read an authorized_keys file and print one fingerprint per key, with its comment:

ssh-keygen -lf /home/deploy/.ssh/authorized_keys

3. Map each key to a person

Match fingerprints against the people and systems you know about. Any key you can’t attribute to a current employee, contractor or named service is a finding.

4. Check which keys are actually used

sshd logs the fingerprint of the key used for each login. On Debian and Ubuntu that’s /var/log/auth.log; on RHEL-family systems, /var/log/secure; with systemd, the journal:

sudo journalctl -u ssh -u sshd --since "90 days ago" | grep "Accepted publickey"

5. Remove what you can’t justify

Delete unattributed and unused keys. Replace shared accounts with named ones so logs tell you who did what.

6. Stop new keys from living forever

Since OpenSSH 7.7, an authorized_keys entry can carry an expiry date. It’s a stopgap, but it beats no expiry:

expiry-time="20261231" ssh-ed25519 AAAAC3Nza... jordan@contractor

For a durable fix, move to short-lived credentials: an SSH certificate authority you operate, or a platform that issues access per session and records it centrally.

How Bastyx is designed to handle SSH

The planned flow, from the engineer’s side, is one command and one touch:

1. The engineer runs ssh as usual.
2. Bastyx checks that the laptop is enrolled and belongs to them.
3. They confirm with their security key, passkey or fingerprint.
4. The policy for that server group decides: allow, step up, require approval or deny.
5. If allowed, a credential valid only for this session is issued.
6. The session is recorded against the person, device and policy, and the credential expires on its own.

This is what zero-trust SSH access means in practice: no standing trust in a key, a network location or a bastion. Every session is checked against who is connecting, from which device, and what policy allows.

Offboarding removes the person’s ability to get new credentials everywhere at once. There are no copies of their key on your servers to hunt down, because there were never any to begin with.