From Plaintext, to BLESS, to Identity: The Evolution of Secure Remote Access

About the author: Leon Fong is a Senior Security Engineer at Adobe Systems.

The Plaintext era

My first introduction to UNIX remote access was via telnet and rsh protocols in college, which was the standard method at the time. But I soon started reading articles about how easy it was for someone to sniff the network and capture passwords since they were being transmitted in plaintext.

On the shared network segments common to university campuses and early enterprise environments, the tools to intercept traffic were freely available, well-documented, and required very little skill to use. The only thing protecting most UNIX environments was the assumption that nobody on the local network was paying attention. That assumption was never a good one.

What can we do about this?

SSH changes the game

With the release of the Secure Shell (SSH) protocol in the 1990s, we finally had a secure method of connecting to a UNIX host that encrypted the password and the entire remote access session, which defeated the vulnerability to network sniffers.

Additionally, instead of using a password, you could use ssh-keygen to generate a private/public key pair and by loading the public key to the remote host as a trusted key, this allowed you to login to your UNIX host by providing the private key instead of a password. However, if your password or your SSH private key is compromised, it would leave your UNIX hosts vulnerable to malicious actors.

What made this risk worse was an operational reality that took years to fully appreciate: SSH keys don't expire.

Once a key pair is generated and the public key is deployed to a host, that trust relationship persists indefinitely unless someone manually revokes it. In growing organizations, authorized_keys files accumulate entries that no one can confidently map back to a current, active employee. Engineers change teams, contractors come and go, and the cleanup of their access is inconsistent at best. Private keys get copied between laptops, stored without passphrases, and occasionally committed to source repositories by accident.

Due to multiple reports of SSH private keys being compromised, Netflix tasked a team to develop a solution to use MFA authentication and utilize the signed SSH certificate feature of SSH to give a much more secure method for remote access to its UNIX hosts.

The insight behind this effort was that SSH has a native signed certificate feature that almost nobody was using. SSH certificates had been part of OpenSSH since version 5.4, released in 2010, but adoption was minimal. Most organizations didn't know the feature existed, and those that did lacked the tooling and workflows to make it practical.

Why SSH certificates are different from SSH keys

An SSH key pair is a static credential. The private key authenticates the user; the public key, stored on the remote host, validates that authentication. There is no expiration, scope, or metadata beyond the key itself.

A Certificate Authority (CA) generating SSH certificates is much more secure as it can be created with a short TTL (SSH keys do not expire), define the source and destination IPs the certificate is valid for, as well as other metadata features. This includes which user accounts (principals) the bearer is authorized to access and what capabilities (port forwarding, PTY allocation, agent forwarding) are permitted.

Critically, the remote host doesn't need to know anything about the individual user. It only needs to trust the CA's public key. When a user presents a certificate signed by a trusted CA, the host validates the signature, checks the TTL and constraints, and grants or denies access. This inverts the SSH key model entirely: instead of distributing individual public keys to every host, you distribute a single CA public key once and the CA handles the rest.

How BLESS (Bastion's Lambda Ephemeral SSH Service) worked

Netflix created a solution called BLESS (Bastion's Lambda Ephemeral SSH Service) using a bastion SSH host that calls a Lambda function in AWS that acts as a CA generating a short-lived SSH certificate that is presented to a remote host for login access. All remote hosts would be configured with the CA's public key so they would trust an SSH certificate signed by the CA.

Even if a user's password is compromised, a malicious actor would be hard pressed to get by the MFA security requirement.

After successfully deploying this solution internally, Netflix decided to release BLESS to the public as open source code in 2016. It was a pivotal moment: the first public proof that certificate-based SSH access was operationally viable at the scale of a major internet company.

However, the proprietary method that Netflix used for MFA authentication and authorization of a user before BLESS was not released to the public. Anyone who wanted to adopt BLESS had to build their own front door.

Building the auth layer: Early cert-based access in the enterprise

In 2018, I was tasked with deploying BLESS at my company.

The initial steps were to develop an MFA authentication mechanism and an authorization method that confirms the user has permission to access the designated host. This was the gap BLESS left open, and filling it required stitching together several systems that weren't designed to work as a single workflow.

I devised an authentication method that utilized our original privileged access management (PAM) platform's OIDC integration with Okta for MFA, using the platform's role-based access control (RBAC) capabilities to define access rights for authorizing a user's access to a remote host. I then created a secure login script on an SSH proxy host that upon successful authentication and authorization of a user, would execute a call to BLESS to generate a signed SSH certificate. This would be presented to the remote host to establish a secure SSH connection.

After successfully deploying this solution at our company, we presented it to our original PAM vendor. They then proceeded to implement their own just-in-time SSH access solution using their platform for authentication, authorization, and as the SSH certificate signing authority.

This experience revealed something important about where the industry was headed.

The real complexity was integrating identity verification, access control, and certificate issuance into a single, seamless workflow. Each of those components existed independently, but making them work together required custom scripting, careful sequencing, and ongoing maintenance of the integration points between them. The fact that a vendor saw what we'd built and immediately productized it confirmed that the market was ready for this model to move beyond custom implementations.

What modern certificate-based access looks like

Over the past few years, using signed SSH certificates has become the standard for secure remote SSH access and multiple vendors have released commercial solutions.

The pattern that emerged from the Netflix/BLESS era has matured into a set of baseline expectations:

• Cryptographic identity tied to a verified user, not a static key
• Short-lived, automatically issued certificates with no standing credentials to manage or revoke
• MFA and identity provider integration as a prerequisite, not an afterthought
• Authorization decisions made per-session rather than per-key-deployment
• Audit trails capturing who accessed what, when, and with what certificate

The manual assembly that early adopters like myself had to build (essentially stitching together an IdP, an RBAC layer, a proxy host, and a certificate authority) is now handled by unified platforms purpose-built for this workflow.

Teleport is one example of where this model has been taken to its logical conclusion. Rather than layering certificate issuance on top of existing tools, Teleport replaces SSH keys, passwords, and static credentials entirely with short-lived certificates bound to cryptographic identity. Certificates are issued just-in-time after identity-provider-backed authentication, and every session carries identity-based audit events including session recording and playback, so there's a complete record of who did what.

The same certificate-based identity model extends beyond servers to databases, Kubernetes clusters, cloud consoles, and web applications through a single access workflow. The operational burden that required weeks of custom integration in 2018 is a solved problem.

What comes next

It's been good seeing the evolution of securing remote access to UNIX hosts from plaintext protocols to encrypted sessions, from static keys to ephemeral certificates, from custom-built auth layers to unified platforms. Each generation eliminated a class of risk that the previous generation introduced.

The same identity and certificate model that matured for human operators is now extending to machines, workloads, and AI agents. Any entity that needs to authenticate to infrastructure and prove it has a right to be there.

I'm just waiting to see what new innovation will be coming next.

Related articles

→ How to Configure SSH Certificate-Based Authentication
→ SSH Certificates: How Do OpenSSH Certificates Compare to X.509?
→ Is JIT the Secret to Engineer Happiness?
→ Securing Identity in the Age of AI: A Buyer’s Guide to Teleport