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.)


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.

Smash a button!
[Total: 2 Average: 5]

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

Today’s article is one my regulars will be expecting, as it is an article that teaches you how to kill processes by their PID (Process ID). This shouldn’t be a long or complicated article and I’d like to think a beginner can understand what it is that we’ll be doing.

If you aren’t familiar with a process PID, you should read the article that I wrote just so that I could write this article:

Find An Application’s Process ID (PID)

Seriously, if you’re at all unsure, read that article. You could even consider that article the first part of this article, except I didn’t want to make my article long. Besides, it’s quite likely I’ll be referring to PIDs in the future.

NOTE: The subject we’ll be approaching today can be quite complicated. In this case, there are all sorts of ways to kill processes. Because of this, we’ll just be covering a couple of very easy ways to kill processes by using their PID. 

Why would you want to do this? 

Well, like it or not, sometimes applications freeze and sometimes applications refuse to close. This is true on every operating system. It can (and probably will) happen. I just tried a pinball application last night and it refused to close. (I closed it using the GUI task manager, not via the PID. Shh!)

Why would you want to kill processes by their PID, especially when you can also ‘killall‘ processes by their name?

Sometimes, you have processes with names like this:

Instead of trying to close that with a command, it has a PID of its own and can be closed using that. It’s so much easier to use the PID for this that you might as well learn how to do it now. Again, it won’t be all that complicated. I’ll do what I can to explain just a couple of choices while we all safely ignore the many other options.

NOTE: This isn’t quite the article I intended to write, so there’s that. The people on the Linux.org forum will know what I mean. This is largely due to my horrible memory.

Kill Processes By Their PID:

Yeah, this is a terminal thing. As such, you’re going to need an open terminal. In most distros, you can just press CTRL + ALT + T and that should be enough to open up your default terminal emulator.

With your terminal now open, let’s have a look at the tool we’ll be using:

If you won’t want to look, the kill command describes itself like this:

kill – send a signal to a process

Handily enough, that’s what we’ll be doing. We’ll be sending a single to a process, specifically to kill the process. You can send other signals. You can send quite a few different signals. Enter this into your terminal:

But, we’re only going to concern ourselves with 9 and 15. Those are the only two we’re going to worry about today. The syntax of the kill command would look like this:

Of course, you’re going to need to know the PID. If you read the article linked in the beginning section, you’d know how to do that. But…

For the sake of this article, we’ll be using ‘shutter‘, as it’s a fine application.

So, if you didn’t read the article about finding an application’s PID, helpfully linked again, we can just use ‘pgrep’. If I run the command on my computer, I get:

So we can now see the PID for Shutter easily enough. (There are numerous ways to get an application’s PID. The pgrep application is generally pretty handy.)

The first command we’re going to try is asking the application to quit. We’re sending a command to the application and asking it nicely to die. That’s -15.

Using the PID gathered in the previous command, and knowing the proper syntax for this command, we end up with a command that looks like this:

Of course, sometimes the application doesn’t die when asked nicely. That’s not all that often, but it’s also not all that rare. It does happen and that’s when we skip trying to talk to the application and send a command straight to the kernel. That’d look like this:

That command tells the kernel to drop the application. In theory, this always works. You may still see the process listed in your list of processes but that’s just a zombie process and nothing to be too alarmed with.

You want to first try -15 because that closes the application more gracefully.  When you use -9 as your signal, you’re more or less just using a hammer to kill the process. If -9 doesn’t work, something is up with your kernel and it’s time to reboot. 

NOTE: The commands I used did not include ‘sudo‘. That’s because I owned the processes. If it’s a process owned by someone other than your user, you will need the correct permissions to kill it, such as sudo.

I am not going to cover them here, but you can send all sorts of signals with the kill command – not all of which kill the process. For more information, I highly recommend the following command (and then digging deeper into the rabbit hole):

I suspect you’ll find that to be more than enough information for one day, even though this article hopefully makes it so simple that a beginner can follow along. Hopefully…


Well, there you have it. Here’s yet another article and this time we’ve learned how to kill processes by their PID. There’s so much more to this, but those are the basics. You can generally ignore the rest as an average user. You can also probably do a great deal of this with the task manager, all with a nice GUI. It’s worth knowing, and doubly so if you spend any time remotely connected to another device via SSH.

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.

Smash a button!
[Total: 2 Average: 5]

Change The ‘sudo’ Password Timeout

Today’s article is going to be a pretty basic article about sudo, where we learn how to change the sudo password timeout. It’s pretty easy to change the sudo password timeout value, and reasonably safe to do so if you use visudo. So, with that in mind, read on!

When you use sudo you’re given a grace period. During that time, you can use sudo again without being asked to type your password again. This is an arbitrary value, typically 15 minutes (I think), and you can customize that value for your particular environment. It’s not difficult.

This is something people may want to change if they’re slow, doing a lot with sudo, or have good physical security. This is also something that someone might want to change for the opposite reason. Some people may want to decrease the length of time that they have with sudo because they work in a shared environment. Who knows? It’s your computer, you can do what you want!

So, what is sudo? It’s how you temporarily use elevated permissions. In fact, I wrote a whole article on this subject, which you can read if you’re so inclined – and I’d suggest doing so if you’re new to Linux:

So, What Is ‘sudo’ Anyhow?

Well then, I mentioned another application. I mentioned ‘visudo’ above.

This may come as a surprise, but I actually wrote an article about visudo! You can read that as well, especially if you’re new to Linux:

Use visudo To Edit The sudoers File

Huh… It’s almost as if I’ve been waiting to write this article for a while and that I took the time to write articles that explain all these things. For a brief moment, one might be fooled into thinking I am good at preparing things. Little do you know… It’d be far more accurate to just say that I’ve written a bunch of articles already. I’d prefer it if you thought it was the former, but there’s definitely a touch of the latter.

Change The sudo Password Timeout:

If you clicked on either of the two links above, you’d know that those tools are used in the terminal. You didn’t click them, did you? Well, you’re going to need an open terminal. In most distros, you can just press CTRL + ALT + T and your default terminal should open. 

With your terminal now open, we’re going to use visudo to edit your sudoers file. In my particular case, we’ll be using Nano. (See? Yet another article you can rely on for more information about Nano!) The command to start banging away on your sudoers file would be simply this:

Now, I can’t say for sure that you’ll be using Nano for this. As you didn’t click the links above, I’ll remind you that visudo uses your default text editor. So, you’ll need to be prepared for that. Your default text editor may be Vim, for example, and you’ll need to know the basics to change your sudo password timeout.

NOTE: If you want, you can change your default text editor. (Did you see that? I did it again!)


With your sudoers file now open for editing, you just enter the following on a new line:

As far as I can tell, most distros default to 15 minutes. So, you can use sudo and then you won’t be asked for the password again for the next fifteen minutes. In the above, you replace the obvious with the obvious. If you wanted 10 minutes leeway without retyping the password, you’d use this command:

If you wanted an hour’s worth of leeway without typing your sudo password again, then the command would just be this:

See? It’s not very complicated at all.

If you want to be fancy, you could include a comment. A comment starts with an # symbol and is thus ignored by the system. You might want to enter something like this:

By adding a comment, you’ll be reminded of what changes you’ve made from the default configuration. This is generally a good idea, especially if you’re going to heavily modify your system.

As this is Nano, you can finish editing the sudoers file by pressing the CTRL + X, then Y, and then the ENTER button. That will save the changes with Nano. If you’re not using Nano, you’ll need to refer to the manual (unless you already know how to save an edited file).


And there you go! You can now change your sudo password timeout value to whatever it is you desire, assuming it’s whole minutes. I do not believe it works with fractions of minutes. You shouldn’t need to reboot or anything. It should take effect immediately and be the new timeout value the very next time you use a command that starts with sudo.

Of course, this comes with some security considerations. If this is a public kiosk, you’d have to be a fool to make this longer. You’d have to be a fool to have sudo access to begin with! That’s why they make guest accounts!

But, if you’re home alone and the neighbors aren’t going to sneak in to steal your wifi password, you’re probably good to go. Heck, if you are daring, you can use sudo without a password. I don’t recommend that, but you can… 

Also, this article contains a whole lot of links to other articles. Google will be pleased! I think it speaks to how many articles I’ve already written more than any foresight on my part.

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.

Smash a button!
[Total: 1 Average: 5]

Find An Application’s Process ID (PID)

Today we’re going to have an article that’s straightforward and simple and it will be about how you find an applications’s process ID (PID). This isn’t the article I want to write. This is a case where I have to write one article so that I can write another article. Otherwise, we’d end up with a two-thousand-word article that nobody would read. 

Let’s start with the basics – and it is very, very basic…

Every process running on your Linux computer has a Process ID (PID from here on out). Each process has a unique PID. Curiously, not all PIDs are using resources. Some PIDs are sleeping. If you work at it and find the right dodgy application (I’m looking at you, Shutter), you can even find zombie processes that are darned near impossible to kill (which might be foreshadowing a future article).

Though, unlike the movies, zombie processes are perfectly okay. They just sit there consuming no resources. Plus, they don’t eat brains (or CPU power), nor do they devour human flesh. They don’t even spread to other processes. In fact, with all that information, maybe calling them zombie processes is a bad idea. It’s not my idea – and they do share one thing in common with zombies in that they can’t be killed. (Zombies are already dead. You can’t kill something that’s already dead!)

There are many ways to find the PID for any given process. You can probably crack open your system monitor and find quite a few listed right there. You won’t even need the terminal for that. Imagine that?!?

(Of course, we’ll be finding PIDs in the terminal. It’s just what we do.)

Find An Application’s PID:

Yup. We’ll need an open terminal. Chances are reasonably good that you can just press CTRL + ALT + T and open up a terminal. Give it a shot, if you haven’t already.

The first thing we’re going to do is generate a giant list of running processes. The first column will be who owns the process (not always you) and the second column will be the PID. To generate this giant list, try this command in said terminal:

It’s a pretty big list, isn’t it? Well, let’s use ‘grep’ to narrow that down quite a bit. You can pipe the output from the previous command into grep and that would look like this:

Using Shutter as an example, the command would look like this:

NOTE: You may find that you see multiple PIDs. That’s because there are multiple instances of the application running. 

If you know the name of the process, you can also try pidof (which should also indicate what it does – it tells you the PID of an application).

So, let’s say we wanted to know the PID of bash. That command would look like this:

In my case, I get four different numbers because I have multiple terminals open, each using bash. No, I don’t consider four open terminals to be abnormal. Well, at least it’s fairly normal for me.

Finally, chances are pretty good that you have ‘pgrep’ available. I did a flip through some VMs and it appears to be installed by default on all the distros I checked. You can use pgrep to find a PID. That would look like this:

So, using Shutter as an example again, we’d try something like this:

Now, not all processes seem to want to be listed like this. For example, if you run the ps aux command, you might have seen processes with weird names like this:

You go ahead and put that into pgrep and let me know if it works for you! It doesn’t work here. But, if you tried pgrep gvfs it will spit out some PIDs for you. At that point, you’re officially above my pay grade. I am not sure and I do not know everything. I did some searching, like a good 30 minutes worth of searching, and didn’t find anything conclusive.

If you happen to know what’s going on, let me know in the comments! Someone is always happy to let me know what I missed (and I’m so grateful for that, I really am.) I swear, I learn more from writing these silly things than you learn from reading them.


Well, have you ever needed to know the PID? It’s a pretty useful thing to know, which I’ll cover in a future article. I didn’t want to write some giant 2000-word article only to have folks gloss over the important bits. Sure, it’d make a nice segue to the next article, but you know darned well that I’m unlikely to write the articles in order. I get bored easily!

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.

Smash a button!
[Total: 2 Average: 5]

How To: Remove A Package With YUM

Today’s article is pretty basic, as the title so helpfully implies, as it simply tells you how to remove a package with YUM. I am writing this article because of a comment sent to me via the contact page. The gist of the comment is that I seldom include information about YUM but lots of information about APT.

I welcome such. If I didn’t, I wouldn’t have the option to contact me! In a similar vein, if I didn’t welcome comments WordPress would happily allow me to disable said comments. I welcome all that sort of stuff, even including the comments I get elsewhere. For the record, some of those comments are so good that they’d be welcomed additions to the articles themselves. Alas, so few people seem inclined to do so and their helpful additions are lost to the aether.

Anyhow, back to the comment sent via the contact page…

The person sending me the message is correct. It’s true. More often than not, I only include information about APT. In my defense, other than servers or playing around in virtual machines, APT is my usual weapon of choice. I’m familiar with it, indeed comfortable with it. As such, my brain just kinda defaults to it.

So, what is YUM? Well, YUM is like APT for people using RHEL, CentOS, Fedora, Rocky, and quite a few other choices, might I say professional, operating systems. While the numbers I can find indicate the APT-using distros dominate the desktop market, it’s almost certain that the server market is dominated by people using a distro with YUM as the package manager.

YUM stands for Yellowdog Updater, Modified. It is the package manager for distros using the RPM (Red Hat Package Manager) formatted, or standardized, packages. It is very old and very stable. Those are not bad things, especially in the server and professional markets – where things like stability are prized. If you used YUM back in the day, I have good news for you. It hasn’t changed! Well, not significantly, as Wikipedia happily tells me that the last stable version was about eleven years ago at the time of this writing. Again, that is not a bad thing! I can’t stress that enough.

Because I don’t cover YUM enough, I figure a nice introductory article will be good. It’ll be a good thing to expose folks to YUM when they’re mostly just familiar with APT. As such, I figure some basic commands are a good place to start. 

So, let’s get to it…

Remove A Package With YUM:

Of course, you use YUM in the terminal. That means you’ll need to have an open terminal. In most distros, you can just press CTRL + ALT + T and your default terminal should open. If this doesn’t open your terminal, you can almost certainly find a quick and easy way to modify your keybindings.

With your terminal now open, the process is pretty simple to remove a package with YUM. The command would look something like this:

You can also use the following format:

Those commands will only remove the package you named. So, if you removed a program like Thunderbird, your configuration files and any dependencies will (should) remain on the system. This is useful for when you need to reinstall an application but want to try keeping your existing configuration.

If you want to also remove your configuration files and any dependencies, YUM will happily allow you to do that. To do so, that is to remove the application, any configuration files, and dependencies, you’d try a command like this:

While it may look similar, it functions differently than autoremove functions in distros like Ubuntu. So, the syntax may look similar, but there are differences between the commands and it may be prudent to remember that. After all, the goal is to remove a package with YUM and not APT.

If you want to get fancy, you can add the following to your /etc/yum.conf to make sure that when you remove a package with YUM it will automatically remove the dependencies and configuration files:

However, adding that command will mean you do exactly what I said you’d do if you did that. You will also remove your configuration files and any of the application’s dependencies. If you’re sure that’s what you always want to do, you can do it! Ain’t Linux awesome?!?


Well, I wanted to write an article about YUM for our RHEL-using peers. I didn’t want it to be too basic, so I figured I’d add a little more to it. The reality is that I don’t cover other distros that often but, in my defense, this is largely aimed at making Linux approachable – or, as the tagline says, “Getting you up to speed.” Most of my readers are going to be using distros with APT and much of my content is generic enough to apply to any major Linux distro.

So, there’s that… If you want to see even more of this type of content, leave a comment (here, preferably) to let me know. I ain’t scared! If this is the type of content that suits you, that’s great and I can write more of it. It’s not hard to include the commands for other distros, it’s just time-consuming.

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.

Smash a button!
[Total: 2 Average: 5]
Subscribe To Our Newsletter
Get notified when new articles are published! It's free and I won't send you any spam.
Linux Tips
Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 International License.