<img src="https://ws.zoominfo.com/pixel/6169bf9791429100154fc0a2" width="1" height="1" style="display: none;">
Blog / SSH

Scaling Your SSH Strategy

StrongDM manages and audits access to infrastructure.
  • Role-based, attribute-based, & just-in-time access to infrastructure
  • Connect any person or service to any infrastructure, anywhere
  • Logging like you've never seen

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.

Bastion Host

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.


About the Author

, Podcast Host, is a dedicated engineer with experience spanning many years and even more domains. He currently manages and leads the Technical Operations team at MIT Open Learning where he designs and builds cloud infrastructure to power online access to education for the global MIT community. He also owns and operates Boundless Notions, LLC where he offers design, review, and implementation advice on data infrastructure and cloud automation.

In addition to the Data Engineering Podcast, he hosts Podcast.__init__ where he explores the universe of ways that the Python language is being used. By applying his experience in building and scaling data infrastructure and processing workflows, he helps the audience explore and understand the challenges inherent to data management.

logo
💙 this post?
Then get all that strongDM goodness, right in your inbox.

You May Also Like

Alternatives to ManageEngine PAM360
Alternatives to ManageEngine PAM360
ManageEngine’s PAM360 gives system administrators a centralized way to manage and audit user and privileged accounts within network resources. However, teams that need to manage secure access to Kubernetes environments or enforce password policies within their privileged access management (PAM) system may want to consider other options. This blog post will cover ManageEngine PAM 360 and some solid alternatives, along with the pros and cons of each.
Machine Identity Management Explained
Machine Identity Management Explained in Plain English
In this article, we'll cover machine identities and address the importance and challenges in machine identity management. You'll gain a complete understanding of how machine identity management works and see the concept in action through real-world examples. By the end of this article, you'll be able to answer in-depth: what is machine identity management?
The difference between SASE vs SD-WAN
SASE vs. SD-WAN: All You Need to Know
SASE is a cloud-based network security solution, whereas SD-WAN is a network virtualization solution. SASE can be delivered as a service, making it more scalable and resilient than SD-WAN. Additionally, SASE offers more comprehensive security features than SD-WAN, including Zero Trust security and built-in protection against Distributed Denial-of-Service (DDoS) attacks.
SASE vs. CASB: Everything You Need to Know
SASE vs. CASB: Everything You Need to Know
In this article, we’ll take a big-picture look at how SASE and CASB solutions fit into the enterprise security landscape. We'll explore the key differences between SASE and CASB and explain how each tool helps ensure enterprise security. You will gain an understanding of how SASE and CASB solutions compare and which might be suitable for your organization.
CyberArk vs. Thycotic (Delinea)
CyberArk vs. Thycotic (Delinea): Which Solution is Better?
In this article, we’ll compare two Privileged Access Management (PAM) solutions: CyberArk vs. Thycotic, with a closer look at what they are, how they work, and which will best fit your organization. We’ll explore product summaries, use cases, pros and cons, PAM features, and pricing to that by the end of this article, you’ll have a clearer understanding of how these PAM tools work and be able to choose the one that’s right for you.