Tag: ssh

Prevent Brute-Force SSH Attacks With fail2ban

Today’s article is one I could have already written and it’s about how to prevent brute-force SSH attacks with fail2ban. The reason I haven’t written it yet is because it either has too much substance or too little substance. I think I can strike a middle-of-the-road here and write an article with just enough substance.

See, and we’ll get to this later in the article, most folks won’t need to do a whole lot more than just install it. You can configure it a great deal, but the defaults are just fine for most people. On top of that, you can even make fail2ban send you email reports but we won’t be covering that in this article. Instead, we’ll largely have directions for installing fail2ban so that you can “prevent” brute-force attacks via SSH. I put the “prevent” in quotes because a diligent attacker could time things, use varied IP addresses, and try brute forcing your login credentials.

I think we need to start at the beginning.

What is SSH:

SSH stands for “Secure Shell” and is a tool to connect to a server remotely. If you check the man page for SSH it is defined as:

ssh — OpenSSH remote login client

This allows you to connect two computers over the terminal. It also comes with SFTP so that you can securely transfer files. You can do a whole lot more with SSH, including forwarding the graphical environment.

Here are a few SSH articles:

Install SSH to Remotely Control Your Linux Computers
Check Your SSH Server Configuration
Show Failed SSH Login Attempts

Then, there are a whole lot more SSH articles. I love SSH, so there have been quite a few articles on the subject. It’s a tool that I use quite often. I encourage familiarity with SSH as it’s sometimes a useful tool to effect a repair on a computer that is otherwise unresponsive to local inputs.

Servers are typically managed with SSH. As you can imagine, servers are a juicy target for malicious people. This means that SSH is a means with which malicious people will use to attack servers. One of the ways they do that is with ‘brute-force’.

What is Brute-Force:

There are many ways that one can try brute-forcing something. The name is as it implies. Rather than knowing the login credentials, they try to brute force them. That means they’ll try one combination of username and password and then keep trying various combinations until they eventually crack the system and figure out the login information.

That is the goal. Their goal is to find the login credentials. Instead of finesse, they use brute force.

This can include a dictionary attack. This can include a progressive attack where they start at the letter a, then try aa, then try aaa, etc. until they find the login credentials. They may also have a list of commonly used usernames and passwords and will systemically work their way through this until they find their way in.

This is one of many attacks and a modern computer can make many attempts in a short amount of time. Add to this modern bandwidth speeds and you can get thousands of attacks in just a short amount of time. It goes even faster if they know one part of the data, such as the username of a privileged account.

Enter fail2ban:

If you’re using a major distro, you have fail2ban available, one way or another. It’s usually easily installed and in your default repositories. When you do install it, you can check the man page. However, fail2ban is described as:

fail2ban – a set of server and client programs to limit brute force authentication attempts.

So, as you can see, fail2ban is the correct tool for the job. After all, and as the headline suggests, we’re trying to prevent brute-force SSH attacks with fail2ban.

Installing fail2ban:

We’ll be using a terminal to install fail2ban. You may also need to remotely connect to the server on which you want to install fail2ban. That too will require a terminal (or some SSH application like PuTTY). Simply press CTRL + ALT and your default terminal should open. If not, you can open a terminal from your application menu.

With your terminal now open, we can install fail2ban.

Debian/Ubuntu/etc:

RHEL/CentOS/etc:

Fedora with dnf:

I believe those are correct. That’s what is in my notes. If they’re not correct, please leave a comment and I’ll update the article. Other distros will have fail2ban available, just search your default repositories and you’ll likely find fail2ban available for installation.

Using fail2ban:

Now that you’ve installed fail2ban, you’re pretty much done. The default configuration is pretty much all you need – but you can customize it. There are a bunch of options available, so you can configure fail2ban in many ways. There are so many ways that we won’t be covering them. They’re reasonably obvious.

Once installed, fail2ban should start automatically. If it doesn’t, run this command to start it:

Next, we’ll make sure to enable fail2ban to start at boot time. That’s this command:

I assume that you’ll want to at least examine the configuration files and I’ll get you started with that. The first thing you want to do is cd to the right directory.

If you run ls you’ll see that there’s a file called jail.conf and you do not want to edit this file itself. Instead, fail2ban will look for configurations in a file called jail.local first. To make that file, you run the following command:

sudo cp jail.conf jail.local 

Next, you might want to make a backup of that jail.local file. 

You can now use Nano to edit your fail2ban configurations:

As you can now see, there are a bunch of options available. They’re far too many to explain here but they’re fairly well described. If any of the options confuse you, you can get help on the man page (man fail2ban ).

After you’ve set fail2ban’s configuration files the way you want them, you’ll need to restart the service for the changes to take effect. That’s done like this:

If you screw up the configuration, just remove the jail.local with this command:

Then restore from your backup like this:

Then, of course, restart the service with this command:

There are a lot of options with this application. You can explore them at your leisure, though I find the defaults to be adequate for most of my needs. As mentioned above, you can install sendmail and have the system send you notification emails. There are many other options as well.

Closure:

Like I said in the beginning, there’s a lot of substance with fail2ban. There’s a lot to it. If I added more to the article, it’d end up quite long. I may write a bit more about this application, but I don’t want to end up with a 2500-word article that will make your eyes gloss over. That doesn’t do me any good and it doesn’t do most people any good. Most folks are going to be fine with the basics before they explore the configuration options on their own.

If you do have a server (or even a personal computer) that’s running SSH, it’s worth your time to install fail2ban. If there’s any chance that someone can try to brute-force your system, they will.

Some bots crawl the ‘net looking for servers that respond on the default SSH ports. They can and will find you. You can also change the port SSH uses for some added obscurity (but remember that obscurity isn’t really security). So, it’s a good idea to prevent brute-force SSH attacks with fail2ban. Yes, it’s a good idea even for us ‘little guys’ who aren’t running servers with valuable information on them.  

Thanks for reading! If you want to help, or if the site has helped you, you can donate, register to help, write an article, or buy inexpensive hosting to start your site. If you scroll down, you can sign up for the newsletter, vote for the article, and comment.

How To: Boot An SSH User

Today’s article will be pretty simple, though it will have a limited scope, as we discuss how to boot an SSH user. The vast majority of my regular readers are ‘simple’ desktop users. This article shouldn’t apply to them; if it does, something may have gone terribly wrong.

I need to point out that if you’re doing this for security reasons, you’ve done something wrong – or you’re getting ready to fire someone and want to ensure any logged-in accounts have been disconnected.

What is this article about?

Well, let’s say you have a server and people are logged in via SSH. Let’s also say you want to disconnect one of them. That is, you want to boot an SSH user. If you want to boot an SSH user, it’s remarkably similar to sending that SSH user a message. You might want to read that article:

Send A Message To Another Logged In User

We’ll be using similar tools, though we’ll also be using tools from this article:

How To: Kill Processes By Their PID (Process ID)

I strongly suggest that you read both of the two links. That will save you some time and I’m going to gloss over some details because one of the great things about previous articles is that it means I don’t have to duplicate work. The onus is yours to read those articles so that you’re familiar with the subject.

In case you haven’t put two and two together, we’re going to boot an SSH user by killing their process ID (PID). It’s a lovely way to do so, perfectly graceful ideally, and will accomplish the goal of booting said SSH user.

This might be something you do when you take a privileged user down to HR to fire them. When they head to HR (and are then led out of the building by security), you can kill any processes they have ownership of, including any SSH sessions they have open. In this case, we’re just going to learn how to boot an SSH user.

So, put on your steel-toed boots ’cause we’re going to boot an SSH user!

(I do… I crack me up!)

Boot An SSH User:

You’re going to need an open terminal and you’re going to need to be connected to the same SSH server(s) as the user. As this is a bit of an advanced article, I’m going to assume you know what those things mean. If you don’t know what those things mean, you probably shouldn’t be operating a server, and definitely shouldn’t be operating a server that has multiple people connected to it.

If you remember (or clicked to read) the previous article, we are going to start with the ‘who’ command. You can simply try this command:

That has all the information you need and you’re looking for the PID as that’s what we’re going to be using to boot the SSH user. We’ll be killing their PID and logging them out immediately. You only need the first field to identify them by username and the sixth field to know the PID. So, you can just use this command:

This will give you an output similar to this:

Using the first field to identify the user, you can see their PID. You can kill their process with the following command:

Or, for example:

If that doesn’t work, and sometimes a process can’t be killed, you can bring out the hammer and tell the kernel to drop the process. You should try the first way as it’s more graceful and using a hammer may result in a zombie process. But, if you want to bring out the hammer, you would use this command:

If the user is logged in more than once, you can boot the SSH user by adding the rest of their PIDs. You just simply add them to either of the two commands. For example:

And that’s how you boot multiple SSH users in one command.

Again, if you’re relying on this for security you’re doing it wrong. This should just be a part of the security process, such as when you’re letting someone go while they were still at their desk. You bring them to HR while security cleans their desk and IT make sure they’re logged out of any and every system. You then escort them out of the building.

Of course, there are probably other reasons why you might want to boot an SSH user. It’s your system, you can decide what to do. You shouldn’t be using this to boot an adversarial SSH connection because if it has reached that point you’re doing security very, very wrong.

Closure:

So, why not? We might as well have an article about how you boot an SSH user. It does not apply to much of my readership, but it’s certainly something worth knowing. It was also tied into a couple of earlier articles, including one from yesterday, so I figured I’d cover this subject while it was still fresh in my memory.

That memory ain’t what it once was! Welcome to old age!

Thanks for reading! If you want to help, or if the site has helped you, you can donate, register to help, write an article, or buy inexpensive hosting to start your site. If you scroll down, you can sign up for the newsletter, vote for the article, and comment.

Disable Inactive SSH Sessions

Today’s article can be used by anyone that has started using SSH on their computers, as we learn to disable inactive SSH sessions. It’s not going to be a very complicated article. This is easy enough for anybody to do, and there aren’t too many ways to permanently mess things up.

What is SSH?

My regular readers will know that I’ve written quite a few articles about SSH. Basically, SSH stands for “Secure Shell” and is a tool you use to remotely control other devices through the terminal. The tool is ancient but still valuable. I use SSH regularly, and that’s not even counting the stuff I do online.

Indeed, I’ve written some SSH articles before:

Install SSH to Remotely Control Your Linux Computers
How To: Restart SSH
Show Failed SSH Login Attempts
(And many more.)

By default, your server/device may not close inactive or idle sessions. It will let you maintain your connection until you tell it to exit. This can be a security issue and it may be worth setting your SSH to disable inactive SSH services.

In this article, we’ll be using Nano and you’ll need to be able to use an SSH connection. If you don’t default to using Nano, you can install Nano or just use the default text editor that you’re more accustomed to. In theory, if you’re just practicing, you could set this up on your computer and then tell SSH to connect to ‘user@localhost’.

Disable Inactive SSH Sessions:

Up above I said, “SSH stands for “Secure Shell” and is a tool you use to remotely control other devices through the terminal.” If you were paying attention, you’d notice the last word is “terminal”. So, you’ll need an open terminal. For most distros, you can open a terminal easily, you press CTRL + ALT + T and you’re all good.

With your terminal now open, you’ll need to connect to the device that’s running the SSH server and enter the following command:

Next, you’ll add a couple of new lines. The syntax is straightforward and easy enough for anyone to understand. There’s a little bit of math, but you can do that math in your head. The syntax looks like this:

The first entry is how long you want to wait to check for an idle connection.

The second entry is how many times you want (set by the first entry) to check for an idle connection.

For example, look at this:

With the above, it’d check for an idle state every 300 seconds (five minutes). It will perform this check 5 times. If the connection is idle for all of those checks, the system will disconnect the SSH user. That’s allowing for 25 minutes of idle time before disconnecting the inactive user. That seems reasonable to me.

You can set those values to anything you’d like, perhaps shorter for an open office and longer if you’re using your home computer and connected to your own devices. The math doesn’t change. It’s just the number of seconds between text multiplied by the number of times the system will perform those checks. If you regularly have many users connected via SSH, you can save some resources by disconnecting them after a reasonable period of inactivity.

As we edited this with Nano, you’ll need to save the file. To do that, you simply press CTRL + X, then Y, and then ENTER and Nano will save the ‘ssh_config’ file.

After you have saved the file, you’ll need to restart SSH for the changes to take effect. That’s easy enough. Assuming you’re using Systemd, you restart SSH with this command:

If you’re still using SysV, the command would be this:

(I don’t bother with that often, I just assume you’re using Systemd. After all, according to the stats I can get, most of us are in fact using distros that use Systemd.)

Closure:

So, if you want to disable inactive SSH sessions, you can use the above as a template. You’ll need to figure out how long you want to wait between checks and you’ll want to decide how many times you’re going to make those checks. It’s simple math that anyone can do. It’s also probably not a bad step to take if you’re dealing with something public or sensitive.

Thanks for reading! If you want to help, or if the site has helped you, you can donate, register to help, write an article, or buy inexpensive hosting to start your own site. If you scroll down, you can sign up for the newsletter, vote for the article, and comment.

How To: Restart SSH

Today’s article will be a very short and easy article, where we learn how to restart SSH. This involves restarting the SSH service. It may not even require a second section, it’s that easy. No, it probably will, just to keep things uniform. So, to learn how to restart SSH read on!

This one is drawn from my own frustration. I recently have had to deal with this a couple of times and I’m not sure why. I’ll root through the logs to figure it out at some point, but the obvious issue here is that I had issues with SSH stopping. More specifically, the SSH daemon/service stopped running.

In my case, I was able to just use another remote connection to the device. I suppose I could have just walked across the house, but it was easier to just use TeamViewer.

Oddly, I’ve had TeamViewer cause problems before. I even have an article detailing how to restart TeamViewer from the terminal (via SSH, I suppose).

So, rather than rebooting the system, I just connected via an alternative method and restarted SSH. It’s easily done.

Restart SSH:

You’ll first need some way of connecting to the device with the stopped SSH service. In the opening section, I mentioned doing so with TeamViewer. It pays to have a backup method to connect to your servers, so you could use VNC or something else that works for you.

If you physically go to the device, or remotely connect to the device, you’ll need a terminal to work with. So, open a terminal. Depending on how you’re connected, you might have to find the terminal in the menu as not all keyboard shortcuts will be passed to the remote computer.

So, once you have a terminal open on the remote computer, try this command:

If that doesn’t work, try this command:

One of those should work for you. Make note of which one works and you, if you think you’ll be doing it often. You can also ‘stop‘ and ‘start‘ services, easily enough, but just a restart should do the trick.

Closure:

See? I told you that it’d be quick and easy. I could use a quick and easy article right now, and this subject just happens to be something I’m currently thinking of. So, you get this as an article, an article about how you restart SSH. Simple and easy…

Thanks for reading! If you want to help, or if the site has helped you, you can donate, register to help, write an article, or buy inexpensive hosting to start your own site. If you scroll down, you can sign up for the newsletter, vote for the article, and comment.

Using The SSH Verbose Mode

That’s right, today’s article is going to be yet another SSH related article, this time it’s about using the SSH verbose mode. It’s handy for debugging SSH connections, plus the information can help you understand more about how SSH works. This is a fine article even for those just starting out with SSH and Linux.

I know, I know… I do a lot of SSH articles. In my defense, they’re fun – and there’s just so much to SSH that many people don’t know. It’s a tool that I use all the time, so it’s only natural that I share articles on the SSH subject. I’m bound to run out of ideas for ’em eventually.

For those that don’t know, SSH stands for “Secure Shell”. It’s a way to remotely control computers within the terminal – though you can actually forward some graphics applications over SSH.

If you’re unfamiliar with SSH, you might try reading some of these articles:

Install SSH to Remotely Control Your Linux Computers
Prevent SSH Root Login
Check Your SSH Server Configuration

Alternatively, you can search for SSH articles and discover quite a few other articles on the subject of SSH. As mentioned in the preamble, and I have gotten pretty formulaic, there are quite a few SSH articles.

There are quite a few SSH articles because there’s a lot to learn. You don’t start off by running, you start by stumbling a few steps and working your way up.

So, with all that in mind, let’s have another SSH-related article…

Using The SSH Verbose Mode:

This article requires an open terminal, like many other articles on this site. If you don’t know how to open the terminal, you can do so with your keyboard – just press CTRL + ALT + T and your default terminal should open.

Of course, you need a computer you can connect to with SSH installed. If you don’t have a remote device, you can enable SSH on your local computer and then just connect to user@localhost and practice all these remote commands.

There are three different modes in SSH verbose mode. They’re indicated with a -v, a -vv, and -vvv. To use them, the command would look similar to the following commanda:

In the first mode, that is -v, you get details about the client-side activities.

In the second mode, that is -vv, you get details about both the client-side activities and the server-side activities.

With the third mode, that is -vvv, you get even more details, more verbosity, about both the client-side and server-side activities. 

For example, this is some of the text output from a -v SSH verbose mode:

ssh verbose mode displayed
And that’s just some of the information you’ll see when you use the SSH verbose mode.

You’ll get even more verbosity as you go up through the levels of SSH verbose mode. This is useful for debugging your SSH connections – but it’s also useful for those who aren’t sure what’s going on behind the scene. When using SSH’s verbose mode, you can see what’s actually going on behind the curtain. That means you can learn more about what’s going on with your SSH connections.

Closure:

So, yeah… It’s another SSH article. I wrote this one ’cause I was thinking about it. I was thinking about it because I’d recently done another SSH-related article. So, I figured I might as well cover SSH verbose mode while thinking about it. Otherwise, I’d have made a note of it in my files and maybe never bothered with the article. Besides, if you want a different article, you’re always welcome to write it yourself and I’ll (quite likely) publish it.

Thanks for reading! If you want to help, or if the site has helped you, you can donate, register to help, write an article, or buy inexpensive hosting to start your own site. If you scroll down, you can sign up for the newsletter, vote for the article, and comment.

Linux Tips
Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 International License.