How passwordless SSH works in EZSSH and Entra ID
EZSSH uses SSH certificates to create short-term access keys signed by our HSM backed certificate authority. They grant just in time access to your resource while creating an audit log that can be traced back to the user and their actions.
How passwordless SSH works
Every connection starts with your corporate identity and ends with a certificate that expires on its own. No agents or long-lived SSH keys required.
A user requests an SSH connection
The user begins with the ezssh CLI, signing in with their Entra ID account and specifying which resource to connect to.
EZSSH evaluates the request
EZSSH checks the user's access to the requested endpoint and the associated approval workflow.
An SSH certificate is requested
An SSH certificate key pair is securely generated on the user's machine, with only the public key sent to EZSSH for signing.
The HSM CA signs the certificate request
EZSSH's HSM-backed CA signs the certificate request, ensuring that the certificate is trusted and tamper-proof.
The user authenticates with their SSH certificate
The user presents their signed SSH certificate to authenticate with the requested resource, using platform-native support for SSH certificate authentication, no agents required.
The SSH certificate automatically expires
After the certificate's validity period is up, it automatically expires and can no longer be used for authentication. A new certificate must be requested to access the endpoint again.
Protocols & technical details
Authentication & issuance
Key protection
Access & deployment
Secure your SSH endpoints in minutes
Start a free trial today, or talk to one of our identity experts about how EZSSH can reduce your IT cost while improving user productivity and security.
Transparent pricing
View pricing detailsStartup
Server and GitHub access management for up to 100 endpoints
Premium
Most popular ✦FIPS 140-3 HSM backed CAs, unlimited endpoints, and SIEM export
Business Critical
One-hour support response and a year of log retention
Frequently asked questions
EZSSH uses SSH certificates to create short-term access keys signed by our HSM backed certificate authority. They grant just in time access to your resource while creating an audit log that can be traced back to the user and their actions.
Yes. Each policy inside each customer's account gets its own HSM backed certificate authority, which creates an identity perimeter limited to that access policy. There is also a bring your own CA option: bring your own Azure Key Vault, give EZSSH create and sign permissions, and you stay in control of your private keys and how they are used.
No. Using a short-term certificate sounds like a lot of work, but the user is not aware of any of it. They type the command and everything else happens in the background. All the user knows is that they have a secure way to connect to their infrastructure.
No. Because EZSSH uses native SSH certificates, most Linux distributions can trust a specified certificate authority and accept certificates from it without constant changes. Once it is trusted, any certificate that meets the requirements the admin set is granted access, so you never run a highly privileged agent or third-party code on your servers.
The EZSSH client creates a new SSH key on the user's computer and the private key never leaves it. Only the public key is sent to EZSSH to be signed, and the certificate is removed from the user's computer once it expires.
Yes. The EZSSH service checks the user's access to the endpoint they requested and applies the appropriate approval workflow. A user can be auto approved, require a dual key approval from another user, or be automatically denied.
The resource owner creates an EZSSH policy and EZSSH creates an HSM protected key unique to it. That policy's key is then added as a trusted CA on your servers, automatically if the resources are hosted in Azure, or by running the scripts EZSSH generated for the policy.