As organizations transition to a zero-trust model, passwordless SSH becomes the only way to protect your SSH endpoints. The first thing that comes to mind is using SSH Keys. They are cryptographically secure, native to Linux so no custom PAM or agent must be running on the endpoint; however, SSH keys are hard to manage:
1) SSH keys do not expire.
2) It is a very manual and tedious task to keep track of who owns each key.
3) Each key must be manually added and removed in each server.
Due to those complications, traditional SSH keys cannot scale to meet today’s cloud needs. As a result, many organizations are looking for an SSH key management solution where the keys are centrally managed and can be rotated by the service.
While centrally managing the SSH keys seems like a great way to solve the SSH access problem, it just puts a band-aid on the wound instead of solving the problem with a modern solution. Here are some of the many drawbacks of centralizing SSH Key management:
The SSH Key Management Solution Requires Access to Your Endpoints: To manage access to your endpoints, most SSH key management solutions need access to your endpoints to either create the just in time (JIT) credentials or to rotate the SSH keys to meet your compliance requirements. This limits the usage of these tools to devices that are accessible from where the solution is hosted, plus it opens the door to attacks such as the SolarWinds attack where the agent is compromised giving access to the attacker to all devices managed by the application.
SSH Keys Are Shared: Most of the SSH key management solutions set a key to access the device (usually the same key is shared across many devices) and then that key is distributed to the users that have access to the vault. This creates a security problem where you do not know who the person that used the key to perform the action was, and since keys are shared, the keys must be rotated each time a person leaves the team.
No Control Over How the User Uses the Key: Since these solutions still rely on an SSH key being downloaded to user’s computer, you do not have control over what the user does with that key. Are they protecting it with a secure password? Are they copying it to their personal computer? Are they sharing it with other users? We have to remember that most engineers are not fully trained in best practices for managing cryptographic keys and might make a mistake that could compromise the infrastructure – our job as security professionals is to ensure that doesn’t happen.
No Conditional Access: Since the authentication into the endpoint is still using SSH keys instead of SSO using your corporate identity, there is no way for you to implement security measures such as conditional access, making your most critical infrastructure the most vulnerable.
After I rained on the parade of managed SSH keys, I must have a solution, right? Well, the answer is SSH certificates, and while I would love to take credit for the idea, I first heard about them thanks to Facebook’s whitepaper. I know, who would have thought that anyone would learn something thanks to Facebook?. SSH certificates, just like SSH keys, are cryptographically secure credentials, and you can easily create SSH certificates on your own with ssh-keygen on Linux. While SSH certificates are similar to SSH keys, they fix most of the issues that SSH Keys have; they expire, have information about the user, and only the CA (Certificate Authority) has to be added to the endpoints, removing the need to manually add and remove each user from each endpoint. The best part? Unlike AD joining SSH endpoints, this is native to Linux and does not require the endpoint to have any connectivity.
As you probably saw in the Facebook whitepaper or our guide on how to create SSH Certificates, while SSH certificates are great, unless you want to sit all day creating SSH certificates for your engineers you need a solution to convert your Entra ID identity to an SSH Certificate. That is where EZSSH comes in!
EZSSH is an SSH Certificate Authority that enables you to create access policies based on your Entra ID groups or Azure RBAC and grant JIT access to your SSH endpoints, allowing you to transfer all your corporate identity security such as conditional access policies and group memberships to Linux without having to run any high privileged agents on your devices.
