Linux: Limit Concurrent Users on Your Server with SSH

Linux is a multi-user system. That doesn’t only mean it can allow a server or desktop to house multiple users, but it also means those users can all log in at the same time. Theoretically, you could have hundreds and even thousands of Linux users logged in to the same server at once.

But would you want to?

Not only could that be a major drain on your system resources, but it could become a serious problem if you have multiple administrators logging in, each of them trying to change configuration options at the same time.

You could even have the same user logged into a single system multiple times.

All of this could lead to chaos…maybe even mass hysteria.

Fortunately, the Secure Shell (SSH), which is the most common way to log in to remote Linux servers, has options that can help with this possible problem and I’m going to show you how to take care of it.

What You’ll Need

The only things you’ll need are a running instance of Linux and a user with sudo privileges. Of course, the machine you’re working on also has to have an internet connection. Otherwise, that’s it. Let’s make some SSH magic.

Limiting SSH Concurrent Sessions

The first thing we’re going to do is limit the number of concurrent sessions that your server will accept. What this does is set a hard limit for the number of SSH sessions that are allowed at once. When the limit is reached, all sessions will be automatically dropped and no one else will be able to log in until someone ends a session.

By default, SSH doesn’t limit the number of concurrent sessions. However, there is a line in the daemon configuration file for that specific purpose. Open the configuration file with:

You can search for the required line by hitting the Ctrl+W key combination, which will bring up the nano search field. In that filed, type MaxStartups and hit Enter on your keyboard, What will appear is the line:

Here’s the explanation of that line:

• MaxStartups is the option
• 10 is the number of unauthenticated connections before SSH starts dropping
• 30 is the percentage chance of dropping a connection, once the limit is reached
• 60 is the maximum number of connections at which SSH starts dropping everything

Enable the feature by removing the # character from the line, so it looks like:

It’s important to note that MaxStartups is the number of concurrent unauthenticated connections to the SSH daemon. This is used to help protect a system from denial of service attacks, so I would suggest leaving it as is (other than removing the # character).

That, of course, doesn’t limit the number of concurrent authorized connections. For that, we need to configure the MaxSessions line, which will look like this:

To limit the number of concurrent SSH logins to 10, change that line to:

Save and close the file.

Restart the SSH daemon with the command:

If you’re using a Fedora-based distribution, the restart command would be:

Limit the Number of Per-User SSH Logins

Let’s say you have admins who have a habit of either forgetting they’re logged in via SSH or simply tend to log in multiple times without exiting. For that, SSH has yet another trick, which allows you to limit the number of per-user SSH logins.

Let’s say you have the user aaron and we want to limit them to a single concurrent SSH login. To do that, open the limits.conf file with the command:

Scroll to the bottom of that file and add the line:

Save and close the file.

There’s no need to restart SSH for this configuration.

Now, if aaron is already logged into the server via SSH, if they try again, they’ll see the following:

Until aaron logs out of the original connection, they will not be able to log back in.

Now, I’m going to make a rather important suggestion. Do not limit all admins to a single connection. Why? There may be times when you’ve made a change to the server and you need to log in with a second connection to ensure the change works. I’ve had certain instances where I’ve logged out of the original connection, only to find the changes didn’t work and I was unable to log back into the server via SSH. When that happened, the only way I was able to gain access to the server was to be on site.

You can also do the same thing with groups, only instead of adding a username, you’d use the group name, like so:

Where groupname is the name of the group in question.

Or, you could simply limit all SSH logins to a hard limit like so:

And that’s all there is to capping the limit of SSH concurrent logins. Make sure to test this out on a non-production server, before configuring your production machines with these limits, otherwise, you could wind up with either a trip or a phone call on your hands.

Jack Wallen is what happens when a Gen Xer mind-melds with present-day snark. Jack is a seeker of truth and a writer of words with a quantum mechanical pencil and a disjointed beat of sound and soul. Although he resides...

Read more from Jack Wallen