In our last post, we discussed some of the challenges that are inherent to the management of SSH keys across your infrastructure as you scale the number of team members and servers. In this post, we will dig into some of your options and the trade-offs that they provide.
Before we get going, let's recap the main criteria that we are concerned with for any solution that we implement. Briefly, we want to ensure that you are able to control authentication and authorization for each user on each server. You will also want to be able to generate and analyze an audit trail in the event of a compromise; however, this may not be an immediate requirement depending on your regulatory environment.
SSH Key Scaling Solutions
Each User Has Their Own Key
When you first start building your systems, it is common to either share credentials with anyone who needs SSH access or to provision accounts and keys for each user on each server. Both of these solutions are manageable when you are dealing with quantities in the single or low double digits of either employees or servers. Some of the challenges associated with the practice of letting each user manage their own keys are:
- Inconsistent key strength between users
- Keys proliferate with no oversight
- It becomes unwieldy to share keys or to provision every server with every user's keys
We will take each of these points in turn.
SSH Key Strength
The overall security of a system is only as strong as its weakest link. As we discussed in the SSH Key Management post, there are a number of options that can be specified when generating an SSH key, and some of the possible configurations can result in a key that is easily compromised. When every user is responsible for generating and maintaining their own keys, there is the potential for them to select one of these configurations, thereby putting all of your infrastructure at risk.
To avoid this situation, you can provide educational material to your employees to make them aware of what the current best practices are. In addition to or instead of education, you can provide tooling that only allows for known good settings when creating key pairs, such as a simple bash script that embeds your preferred options and eliminates the need to look up parameters. A third option is to generate keys on their behalf, but this requires that you have an established channel for securely transferring the sensitive private key.
SSH Key Proliferation
Another problem with allowing each of your users to create and maintain their own keys, is that you have no oversight as to who has which keys and on what machines. This leads to a situation where you can never be sure whether a given SSH session is being conducted by an authorized individual or if their private key was compromised. Having no visibility into the location and controls over each individual's keys also means that it is difficult, if not impossible, to enforce key rotation policies.
Server Provisioning
The last item to discuss relating to individual management of SSH keys is that, in order for any of those key pairs to be useful, they need to be provisioned on the servers that each SSH user requires access to. In a small team that manages a small number of instances, this task can be performed manually or via your configuration management strategy of choice without too much difficulty.
Once you reach a measure of scale for either axis of people or servers, it becomes impractical to provision, track, and expire access across your infrastructure. At small scales, it is likely that every user has access to every server, but with growth comes an inevitable level of specialization, requiring greater care when granting permissions. In an environment where any measure of compliance is mandatory, this is even more important to get right.
Once you reach the tipping point where individual key management is no longer practical or possible, the next common strategy is to use some form of bastion host. A bastion host is a server that is publicly accessible and can be provisioned with each user's key who should be granted access to your network. From that host, the user can then access the private network and log in to the destination servers.
An initial benefit of the bastion host is that it reduces the many-to-many relationship of users to servers to a many-to-one situation. Now you only have one location to populate with your users' keys, meaning that there is only one place to look when revoking access as well. By consolidating the potential entry points to your network, it is also possible to more closely monitor access patterns, though not the contents of the session.
This approach works particularly well when your network topology is relatively flat, and the bastion host is able to access the destination servers directly. As you add more network segments, you can either add more bastions or update the routing tables to allow your existing bastion access to the new environments. By scaling to additional bastions, you begin approaching the original problem of managing multiple keys on multiple hosts.
Another consideration when working with Bastion hosts is how to control access for specific users to specific hosts. You can provision the bastion with multiple keys, each of which grants access to a specific set of servers; otherwise, you begin to enter the realm of integrating additional components such as identity management to the login path of your server. There are projects that can help with this, but they introduce another moving piece that diverts more of your time and attention away from the primary goal of solving your business problems.
In essence, a bastion host is just a proxy for connecting from your laptop to your servers, but one that requires a dedicated server and all of the maintenance and management that goes along with it.
An Infrastructure Access Platform
The proxy approach to managing SSH access to your systems is a viable one in principle, what makes the difference is how it is executed in practice. The StrongDM architecture is also proxy-based, with the critical difference being how it manages authentication and authorization.
Rather than needing to integrate your identity management system with OpenSSH, or the PAM system, on each server, you only need to do it once when you set up StrongDM. Alternatively, you can use the built-in user and role management within the StrongDM admin interface. This will give you a single location to manage role-based access control for all of your servers, as well as assign your users to the appropriate role based on their needs and responsibilities.
To set up your environment to work with StrongDM, you will still need to provision keys on the destination hosts, but only the one needed by the StrongDM gateway. Once that is in place, your users will request a session from the gateway and be granted a temporary credential that is only valid for single use. Upon connection, all of their activity will be logged within StrongDM for your later review and analysis. Because all of the traffic is routed through the StrongDM gateway, this audit log also applies when using a bastion or jump host to access additional servers.
By delegating authentication to StrongDM and removing it as a concern of your SSH servers, you also gain easy access to integrations with multi-factor authentication (MFA) providers. For further scaling, StrongDM natively supports hierarchical deployment patterns so that your users don't have to keep track of which proxy to use for which environment.
If you want to learn more about how StrongDM can simplify your SSH strategy, and make it scale with your business, book a time today to talk to one of our experts.
