If you’re a Microsoft Active Directory expert, your first instinct for managing access to your Linux endpoint(s) is probably to domain join your Linux VMs to Active Directory. The TL;DR here is DO NOT DOMINA JOIN LINUX VMs to ACTIVE DIRECTORY…it’s just an awful idea. You’re going to run into issues with DNS, Privileged Agents, No MFA, and just a generally not the best or most secure user experience.
The logic isn’t entirely off - the idea being this is that you’ll theoretically be able to centrally manage your Linux endpoints from a familiar location and not have to deal with Linux-specific issues; however, the Linux operating system was not designed to be managed by a central Active Directory. This forces you to run multiple highly privileged agents and services in your Linux machine to emulate the Windows behavior in an Active Directory environment. The complexity adds the same possible issues as with a Windows domain joined machine, except the debugging now must be done from a Linux machine that might not have the same tooling as its Windows counterpart. Read more about how SSH is the weakest point in your infrastructure.
So, what is the problem with SSH keys? Well, SSH key pairs allow users to connect to remote accounts without having to use the password of the remote account. This is useful if you’d like to not have to enter the password to an account you own and access frequently, and might even pass the sniff test for zero-trust. We’ve all been hearing the vast majority of cybersecurity leaders saying that we need to remove passwords. So why are SSH keys not good enough for zero-trust? First of all, it doesn’t meet the multifactor requirement (let’s be honest, no one puts a password on their SSH keys), and they don’t expire, meaning that you have manually remove them from the server studies show that an average server has over 200 keys and 90% of those keys are not used. Watch the webinar below to see more about just how vulnerable this can be!
Short term SSH certificates enable all of the cryptographic benefits of SSH keys, but with just in time access! We’ve previously written about how SSH certificates work, but here’s a quick recap… SSH certificates are the industry’s response to non-expiring SSH keys. SSH certificate are an SSH key signed by a trusted SSH Certificate authority, this allows you to only have to add the keys of the CA to the server, and then all keys signed by that key are granted access. The world’s biggest organizations have been using tools such as EZSSH to get started with zero-trust SSH and create short term certificates to grant just in time access to their servers. This removes the need to lifecycle keys and helps you meet the strictest compliance requirements.
EZSSH is the only agentless Linux access management tool for passwordless SSH authentication in the world. Leverage your existing AAD groups and users to manage access and create short term SSH Certificates. Get your Active Directory based control, while using Linux based authentication. Remove the need to manage, rotate and remove SSH keys for all your users and hosts! It’s so simple, that all the user will see is the same-old, familiar SSO experience using their AAD Identity. No more keys in engineers’ desktops waiting to be stolen by bad actors. Simply put, EZSSH enables a better approach to endpoint management!
As seen in the video above, the user flow for accessing the system is clearly much quicker and easier than creating an SSH key and then adding it to the endpoint. As long as the user is a member of the policy assigned to the endpoint, all the user has to do is run “ezssh ssh username@endpoint” or use our UI tool.
We’ve removed the grunt work associated with running a secure and compliant SSH Certificate Authority and created an easy-to-use, policy-based system. This enables you to manage user access by adding AD groups and users. To set up access in the Linux Machine, it is as simple as running the script created by your policy that adds the CA as a trusted entity for user authentication. No agents, extra PAM modules, or complex setup just native Linux Authentication.
In the background, EZSSH will use the user’s AAD account, authenticate our service, verify the user has access to the endpoint, and create a short term SSH certificate that will expire once the defined period expires. This essentially removes the need to cycle accounts altogether. Since a new cryptographic based credential is created each time, it meets and exceeds security and compliance requirements for credential rotation. If you’re anything like our Development team, we know you’d most likely prefer to read our EZSSH documentation about zero trust ssh rather than speak with a member of our team, so feel free to do so. That said, we’re always happy to chat! Thanks for reading and be sure to dig into the suggested reading below to really begin your journey towards zero trust for Linux!
