As the great Mark Twain once wrote in response to reading his own obituary in May of 1897 , “reports of my death have been greatly exaggerated.” Fast forward nearly a hundred years to 1995, and a Finnish computer scientist named Tatu Ylönen created a secure transport protocol known simply as Secure Shell (SSH). What do these things have to do with each other? Nothing, aside from perception.

In its most practical terms, SSH enables users to establish a secure, remote connection with a Linux-based machine via a Command Line Interface (CLI). SSH is the de facto standard for secure server access, and has survived the test of time, despite a significant shift in how infrastructure is operated in the cloud.

At Okta, we embrace the shift towards the cloud operating model, where resources are dynamic and ephemeral, by adapting the underlying security properties of SSH to fit. Our customers use Okta Advanced Server Access  (Okta ASA) to securely automate identity and access controls for their teams to use SSH safely. And we’ve just reached a significant adoption milestone by registering over 1 million SSH logins per month… and growing!

In this post, I’d like to talk through some of the trends surrounding the cloud operating model, the continued role SSH plays in securing remote access, and how Okta has helped our customers elegantly solve a nagging pain point.

With Great Power Comes Great Responsibility

As the de facto standard for remote access to Linux servers, SSH is naturally a common target for attackers attempting to infiltrate a company’s network. The transport protocol is inherently secure; however, the backing credential mechanism is prone to human error-with potentially catastrophic results. SSH Keys, which are cryptographic key pairs designed to be an attestation of trust, require great care to ensure they don’t fall into the wrong hands. There is no way to guarantee a link between an SSH Key and an identity, so in many ways, possession is 10-tenths of the law.

As such, companies have traditionally been forced to do one of the following:

• Implement a security policy for users to regularly manage and rotate their personal SSH Keys (easiest, least secure).
• Operate a secure vault service that can store SSH Keys, checked out on demand (harder, more secure).
• Purchase and deploy a privileged access management product to act as a gateway for remote access (hardest, most secure).

I imagine you can see the pattern here: as with so many things, you get out what you put into it. But look, security is changing, and fast. First of all, the hardest solution isn’t always the most secure, but more importantly, who has time for all that extra hard work??!! We’re all forced to do more with less, but security teams also have the added challenge of protecting the company without getting in the way of the business. Not an easy thing to be on the hook for by any means.

We understand this continued balancing act, and design our products to be the most secure and easiest to use solution on the market. Before we get to the details of how we enable our customers to achieve a better outcome with Okta ASA, I’d like to address the perception that SSH is dead in the modern cloud era.

The Kubernetes Challenge

With the shift towards the cloud operating model, Kubernetes has emerged as everyone’s favorite _configuration management plane/orchestration layer/CLI/runtime/service mesh/dev environment _ platform. Here’s a phrase I sometimes hear, “We’re all in on Kubernetes, we won’t need SSH access anymore.”

That sure sounds like a dream: a unified abstraction layer that removes all human interaction from managing elastic, multi-cloud infrastructure. Kubernetes is certainly poised to become the proverbial operating system of the cloud, but it does introduce a whole new set of complexities and considerations. Here’s a small sampling of scenarios where human interaction is still required:

• Logging into underlying hosts to run diagnostics scripts, inspect logs, debug network issues, etc.
• Writing and debugging YAML code to describe and configure target environments, services, runtimes, etc.
• Monitoring performance of networks, infrastructure, services, etc.

Standing strong and tall amidst all this innovation and change is SSH, because you just can’t replace that sturdy, direct connection between a user and a host operating system. Even the most automated of environments needs human access in case of emergency, but there’s more to it than that-automation needs security controls too. SSH still fits the bill for both human and service-level access.

The mental picture we all likely have in our heads here is a systems administrator sitting at their desk, connecting to a single Linux server from their terminal by typing, "ssh ". While the direct user-to-server login is a common use case, the use of SSH is also prevalent in:

• Developers writing and running scripts that connect to many servers at once to run a series of diagnostic tests
• Configuration Management software (Terraform, Chef, Puppet, Ansible, etc.) that connect to target hosts to make local changes
• CI/CD automation tools that connect to production servers to configure runtimes and push software builds

Let’s revisit the problem with SSH Keys. The traditional PKI (Public Key Infrastructure) that backs SSH was built for a different time, where a key exchange meant enough to grant trust. The core problem lies with the false assumption that ownership of a private key equates to an identity profile. While we may say “Alice’s private key”, there’s no associated authentication process that could verify it was Alice, who generated the key pair to begin with, or that Alice is the only person who currently possesses the private key.

As these keys get issued and distributed across fleets of dynamic infrastructure and cloud services, the challenge only compounds. Each public key accrues more privileges over time; the longer it’s been alive, the more likely it’s been shared with a resource, making it extremely difficult to track and subsequently revoke. With this model, time is a bug that can’t be fixed.

In a Zero Trust world, a meaningful trust attestation is correctly adhering to a policy that states a person (or service) from a known device can access a specific resource at a given time. It’s not necessarily about the credential itself, it’s about the context surrounding the request. Even so, we still need a way to represent the identity and permissions associated with the attestation that was made.

#cloud #security #kubernetes #ssh #okta asa