SSH access is everywhere
SSH access is everywhere within your IT environment. It is the de-facto method for Linux, database, and network admins and application support teams to securely connect to servers and applications within them - whether they are on-premise or in the cloud.
Let's explore the ways to authenticate with SSH:
- SSH access with passwords
- Passwordless SSH
- Passwordless and keyless SSH
Contents
1. Traditional ways: SSH access with passwords or passwordless SSH
2. The new way: passwordless and keyless SSH access
3. Caveat emptor - all SSH keys don't disappear overnight
4. Migration to Zero Trust SSH access
Traditional ways: SSH access with passwords or passwordless SSH
Traditionally, there have been two ways to use strong authentication with SSH for remote access to servers. The first one is configuring a password that is required for each remote SSH session.
The second one is setting up a public and private SSH cryptographic key pair and then configure the public key on a server to authorize access - and grant anyone who has a copy of the private key access to the server.
About 80% of SSH connections are used for machine-to-machine, automated tasks, and processes that overwhelmingly utilize SSH keys for authenticating that access.
Both SSH access types have led to management problems, especially in large scale use. The SSH with password method has led to complex password management, rotation and vaulting requirements whereas the passwordless SSH has caused the proliferation of SSH keys.
Over the years, enterprises realize that either they are rotating thousands or passwords per day or that they have hundreds of thousands of unmanaged SSH keys in their environment. This is due to the explosion of using SSH to access cloud assets, DevOps integrations, CI/CD pipeline, provisioning, and monitoring tools.
Either way, both methods easily lead to serious security risks and cause unnecessary management overhead.
The new way: passwordless and keyless SSH access
The increase in usage of SSH keys only increases the burden on organizations implementing responsible SSH key management processes.
Fortunately, a paradigm shift in SSH access management is already happening.
The future of SSH access is passwordless and keyless. Authentication moves away from static credentials towards the use of Just-In-Time (JIT) provisioned, short-lived or ephemeral certificates granting Just Enough Access (JEA) to align to a Zero Trust model that is shaping the future of data security.
If that sounds complicated, it really isn't. In fact, it's very elegant. The whole concept is built around the idea that authentication no longer requires permanent credentials like passwords or SSH keys. Instead, every session is authenticated just at the time of establishing the connection, using short-lived certificates. The certificates has the required secrets to establish the connection baked in, but they automatically expire within minutes of authentication.
This method simply doesn't leave any keys or passwords behind to be managed! What's more, the user doesn't handle or see any secrets either. It's all happening under the hood.
Just think about it. Say goodbye to password vaulting or rotation. Bid adieu to managing thousands of leave-behind SSH keys.
Caveat emptor - all SSH keys don't disappear overnight
It is worth noting, however, that due to internal working of, for example, OpenSSH:
Switching SSH access to using ephemeral certificates, on its own, does not invalidate left-behind SSH keys.
In fact, existing SSH keys remain valid and usable for authentication as long as they are configured.
Not only that, a solution that only concerns itself with providing access using ephemeral certificates leaves wide open the ability for individuals to self-provision SSH keys used under the radar.
In enterprise environments, the need to maintain visibility and control over existing SSH keys remains while preparing for the future of keyless and passwordless SSH access.
Migration to Zero Trust: passwordless and keyless SSH access
At SSH Communications Security, as the inventor of the Secure Shell (SSH) protocol, we develop the leading solution for managing SSH keys. Our Universal SSH Key Manager (UKM) Zero Trust Edition introduces unique capabilities to facilitate SSH access using ephemeral certificates while allowing the reign over existing SSH keys.
Nerd alert! Public key cryptography, SSH configurations, and authentication methods below.
UKM keeps an up-to-date inventory of your SSH key estate and a trust map revealing what access each private key provides using the keys’ fingerprints. UKM Zero Trust Edition introduces a component, PrivX, which acts as a Certificate Authority (CA) and issuer of Just-in-Time (JIT) SSH certificates used for user authentication.
The migration workflow allows admins to execute migration action on existing SSH keys to replace the currently configured authorizations (static credentials) with ephemeral SSH certificates with a single click/API call. This effectively eliminates the need for SSH key management at large - a migration of existing SSH key authentication to the new Zero Trust SSH access paradigm.
How is this done?
Preparing for the shift towards Zero Trust SSH access that is passwordless and keyless comprises a one-time provisioning step to set the stage for the actual migration.
Preparing for migration to Zero Trust SSH access
Before replacing the SSH keys and going keyless and passwordless, target servers are prepared for the migration by updating their SSH servers’ configurations as follows:
Since PrivX acts as a CA issuing the short-lived user certificates, SSH server configurations on target hosts need to be updated to trust that CA, in order to accept those user certificates. This configuration change is a one-time operation that is scripted and easily executed with existing configuration management tools.
Moving to Zero Trust SSH access without keys or passwords
Now that you are ready for the main task, let's consider the following use case - migrating away from SSH keys used for authenticating configuration management tools such as Ansible, Chef, etc.
Use case: This use case is representative of a machine-to-machine scenario in which preserving the non-interactive properties of the access is paramount. In this use case, we'll retain the use of public-key authentication between the source and the Zero Trust component, in order to showcase both how the migration of existing keys can be achieved without disrupting existing processes and at the same time gain role-based access control (RBAC) and full auditing and control of SSH sessions.
Nevertheless, other authentication methods, including multi-factor authentication (MFA), or preserving direct connections between source and destinations that do not traverse through the Zero Trust component while still using ephemeral certificates are also possible.
UKM’s discovery process creates an inventory of all private SSH keys and the corresponding authorized keys that grant access to target servers.
Migration of SSH key-based access is done by initiating a “MIGRATE TO ZERO TRUST” action on a chosen private key. In our use case, a private key grants access to the ansible user on a number of nodes.
As a result of this action, any access granted by authorized keys with a matching fingerprint will be migrated to using ephemeral certificates. The process is fully automated and requires no manual intervention or configuration changes to the systems.
Behind the scenes of migration to Zero Trust SSH access
Behind the scenes, UKM orchestrates a number of configurations to facilitate the new access. It places the targets in a role in essence implementing RBAC for the chosen set of SSH access. Additionally, in this scenario, UKM also creates an SSH client configuration to transparently redirect SSH connections initiated by the source account through the Zero Trust component, PrivX.
To illustrate the changes to the connection consider the SSH connection before the migration where the source initiates SSH connection to user1@10.1.54.192. In the split terminal below, the top shows the source connecting via SSH to the target. The lower part displays the syslog message logged by the SSH server as a result of this successful authentication. The authentication is using static RSA key.
Once the migration process is complete, issuing the very same SSH command results in a successful authentication. However, this time the access is done using certificate authentication, and in the chosen scenario, the access is diverted through the Zero Trust component in order to allow full capture and control of the SSH session.
The changes are completely transparent to the client and no modifications are necessary to integration scripts or automation that could be using SSH access.
The migration to using ephemeral certificates removes the need to distribute and manage authorized keys on targets.
Summary
SSH key management processes can be complex and challenging, especially in highly dynamic enterprise hybrid cloud environments.
We see the future of SSH access following Zero Trust principles. It's a paradigm shift where you no longer attempt to manage static SSH encryption keys but instead migrate to just-in-time (JIT) certificate-based authentication.
In this model, access is granted on-demand at the time of establishing the connection. Instead of using keys, access is granted with short-lived certificates that are invisible to the user and that expire automatically after the connection. This means that there no longer are any permanent SSH encryption keys left behind to be managed.
This is an evolutionary step for Enterprise Key Management (EKM). We call it Zero Trust SSH access that has the following benefits:
- Greatly reducing the need to manage static SSH keys - often reducing their numbers by the thousands.
- Significantly simplifying the key rotation process with fewer keys to rotate.
- Enabling session recording and full visibility into the SSH connections.
- Full audit and control of SSH connections - including machines.
Learn more about UKM Zero Trust Edition >
