We’ve been doing SSH authentication wrong for decades. Static SSH keys sit on laptops waiting to be stolen. Passwords get phished. Even multi-factor authentication can be bypassed with a well-timed social engineering attack. We’ve accepted these trade-offs because, well, what else is there?
Turns out, there’s a radically different way to think about SSH authentication—one that combines hardware tokens, cryptographic proofs, and stateless verification in a way that makes traditional approaches look almost quaint. Here are five counter-intuitive insights from a proof-of-concept that bridges YubiKey OTP, HashiCorp Vault, and SSH in ways you didn’t know were possible.
1. Your SSH Key Can Be Single-Use and Still Work Perfectly
Think about that for a moment. SSH keys are supposed to be persistent. You generate them once, distribute the public key, and use the private key for years. That’s the mental model we’ve all internalized.
But what if every SSH session used a completely ephemeral certificate that self-destructs after two minutes?
This system does exactly that. Instead of relying on long-lived credentials, it generates a short-lived JWT that serves as an SSH certificate. The certificate contains your SSH public key, but here’s the twist: that public key is only valid for the duration of the JWT’s lifetime (120 seconds, in this implementation).
“Password-less, single-use, fully auditable in Vault logs”
No key rotation. No certificate revocation lists. No wondering if an old laptop in a drawer somewhere still has valid credentials. The authentication material literally expires faster than it takes you to make coffee.
Why this matters: In a world drowning in credential compromise, the best defense isn’t stronger passwords or better key management—it’s credentials that cease to exist before an attacker can use them.
2. OTP and SSH Live in Different Universes—Except They Don’t
One-Time Passwords belong to the world of web logins, TOTP apps, and SMS codes. SSH belongs to the realm of public-key cryptography, certificate authorities, and authorized_keys files. These are fundamentally different authentication paradigms.
Or so we thought.
This architecture proves that OTP can become a cryptographically verifiable proof of possession for SSH—by having Vault sign the OTP. The YubiKey generates a one-time password, Vault cryptographically signs it using its Transit engine, and that signature becomes part of a JWT that the SSH server can verify.
The OTP itself is never transmitted in plaintext. It’s signed, packaged, and verified—transforming a traditionally “something you have” factor into a non-repudiable cryptographic assertion.
“By letting Vault sign the OTP, the OTP becomes a verifiable proof of possession usable for SSH login — enabling stateless, hardware-backed SSH MFA.”
The insight: When you can cryptographically bind an OTP to a public key and verify both together, you’re not just adding MFA to SSH—you’re creating an entirely new authentication primitive.
3. The SSH Server Doesn’t Need to Store Anything About You
Traditional SSH authentication requires the server to maintain some state about who you are: an authorized_keys file, a certificate authority it trusts, a user database, something. Even “passwordless” systems typically require pre-provisioning public keys.
This system? The SSH server knows nothing about you until the moment you authenticate.
When you attempt to connect, the server runs a PrincipalsCommand script that validates your JWT against Vault’s public key. If the JWT is valid—meaning it was recently issued by a trusted Vault instance, contains the correct audience claim, and hasn’t expired—the server grants access on the spot.
AuthorizedPrincipalsCommand /usr/local/bin/verify_ssh_jwt.sh %u %k
AuthorizedPrincipalsCommandUser vault
No pre-enrollment. No allowlists. No database lookups. The trust model is entirely external: “If Vault vouched for you in the last two minutes, you’re in.”
Why this is radical: This is zero-trust authentication taken to its logical extreme. The SSH server doesn’t trust you—it trusts Vault’s assertion about you, and only for 120 seconds.
4. Physical Security and Cryptographic Proof Aren’t Separate Things Anymore
We usually think of hardware tokens (like YubiKeys) as physical security: something you have to physically touch to prove possession. Cryptographic signatures, meanwhile, are logical security: mathematical proof that a message came from a specific key.
This system collapses that distinction.
When you touch your YubiKey to generate an OTP, that OTP is immediately signed by Vault’s Transit engine with your SSH public key as context. The resulting signature binds three things together in a single cryptographic proof:
- Physical possession (you touched the YubiKey right now)
- Cryptographic identity (this is your SSH public key)
- Temporal validity (this happened within the last 120 seconds)
The SSH server verifies all three simultaneously by checking the JWT. There’s no “step one: verify the physical token, step two: verify the key”—it’s one atomic verification.
“OTP provides physical possession proof (touch YubiKey). Vault Transit signing ensures OTP integrity & ties it to the key.”
The implication: When hardware and cryptography fuse like this, you get authentication that’s resistant to both physical and digital attack vectors in ways that neither could achieve alone.
5. Auditability Happens by Default, Not as an Afterthought
Ask a security team about their SSH access logs and you’ll usually hear about host-based logging, centralized syslog, maybe some SIEM integration if they’re sophisticated. But audit trails are always retrofitted—you build the access mechanism first, then figure out logging later.
This architecture inverts that.
Because every authentication flows through Vault, every login attempt is automatically logged in Vault’s audit system before the SSH connection even succeeds. You get:
- Who requested access (the
subclaim in the JWT) - When they requested it (JWT issuance timestamp)
- What key they used (the
ssh_certclaim) - Which YubiKey OTP they presented (the
otp_sigclaim)
And because the OTP is cryptographically signed, the logs are tamper-evident. You can prove not just that someone accessed a system, but that they possessed specific hardware at a specific time.
The deeper truth: When authentication and audit are the same operation—when you literally cannot authenticate without creating an audit trail—security becomes something you can’t opt out of, even by accident.
What This Means for the Future
The conventional wisdom about SSH is that it’s a solved problem: keys work, certificates work, and if you want MFA you can add it on top. We’ve optimized password rotation, key escrow, and certificate lifecycles because we assumed those were the constraints we had to work within.
But what if the constraints themselves were wrong?
This proof-of-concept suggests a different future: one where authentication is stateless, ephemeral, and hardware-backed by default. Where audit trails are cryptographic byproducts rather than operational overhead. Where “zero-trust” isn’t a buzzword but a literal architectural property—the server trusts nothing except real-time cryptographic assertions.
We’re not quite there yet. This is still a proof-of-concept, with rough edges and deployment challenges. But the underlying ideas—OTP as cryptographic proof, JWT as portable trust, Vault as stateless verifier—point toward authentication patterns that feel impossibly elegant once you see them.
The real question isn’t whether this specific implementation will take over the world. It’s whether, five years from now, we’ll look back at persistent SSH keys the same way we now look at FTP passwords: a necessary compromise from an era before we knew better.
Are we ready to rethink authentication from first principles—or are we too invested in securing yesterday’s architecture?
Try It Yourself
Want to experiment with this approach? The complete implementation, including setup scripts and configuration examples, is available in the GitHub repository:
👉 Visit the knock-knock-ssh repository to explore the code, try the proof-of-concept, and see stateless SSH authentication in action.
The future of authentication might be stateless, hardware-backed, and ephemeral. And you can start testing that future today.