Security Archives • Page 3 of 14 • Linux Tips

Add User To The ‘sudoers’ Group

Today we’ll have a pretty straightforward article that’s meant for those who want to add a user to the ‘sudoers’ group. I have tested this in Ubuntu, specifically in Lubuntu, and it works. It shouldn’t be a complicated article, one easy enough for anyone to follow.

I am not 100% certain if this will work in other distros, so comment and let me know if it works with others. It should work in Debian, the official Ubuntu flavors, Mint, POP!_OS, ElementaryOS, and more. That much I’m pretty confident of, but I’ve done limited testing.

This article is going to assume you’re using ‘nano’ as your default text editor. That’s important for this, otherwise, you’ll need to change the directions to match your text editor of choice.

Let’s Install Nano (With Some Bonus Information)

We’ll be using a tool known as ‘visudo’. The man page defines it as:

visudo — edit the sudoers file

It’s important to use visudo to edit the sudoers file because it checks for errors and will prevent you from making syntax errors. It can’t correct bad information, but it can prevent you from making some basic mistakes.

What is the ‘sudoers’ file?

Well, simply put, that’s the file that decides who has the rights to access sudo, and what rights they have to do so. A sudo user has administrative privileges, that is the ability to edit files that can’t be edited by a regular user. The sudo users can do things like change system files, change system settings, and add or remove software. They’re administrators (though you technically can give them limited rights, which is a topic for another article) so to speak.

So, What Is ‘sudo’ Anyhow?

You should make good choices when deciding which accounts have sudo access. They, at least by default, have the keys to the kingdom. A user with sudo access has complete control over the system. This isn’t always a good thing.

Many distros, including Ubuntu, use sudo instead of a root account. Root also has the keys to the kingdom. It’s a good way to view sudo as temporarily elevating the user’s rights to that of the root user. It should be obvious why this is beneficial.

Most of us don’t want our account to have root access all the time because it stops us from editing files we might not want to access – and the software we use also only has our regular user’s limited access to the system. Some folks are into running as root, and some distros have root enabled by default. The great thing about Linux is the choices available, including choices about security.

How To: Enable The Root Account in Ubuntu
How To: Graphically Login as Root in Ubuntu

(It’s generally suggested you not follow the directions given at those two URLs, but I’m a big fan of choice and of sharing information. So, you can do what you want. I do ask that you be careful and be a good netizen.)

That’s what we’ll be doing today. We’ll be learning how to add a user to the ‘sudoers’ group (file I suppose). Those user accounts will then have sudo access, the keys to the kingdom. There are a ton of valid reasons for doing this, and some not-so-good reasons. It’s your device. You do you!

Add A User To The ‘sudoers’ Group:

Yes, this article requires a terminal. I don’t know of a GUI way to accomplish this task. I’m sure there is one, but I don’t know. If you know of one, feel free to add a comment. Otherwise, press CTRL + ALT + T and your terminal should pop open.

With your terminal now open, you can easily just run the following command:

usermod -aG sudo <username>

1	usermod -aG sudo <username>

Of course, that’s the easy way…

If you want, you can manually edit the sudoers file. You’ll want to know how to do this if you only want to give the user elevated permissions to certain directories or files. So, I’ll include that. We can use this article as a reference article for a future article.

To manually edit the sudoers file, you just run the following command:

sudo visudo

1	sudo visudo

You’ll then add the following line at the bottom of the file:

<username> ALL=(ALL) NOPASSWD:ALL

1	<username> ALL=(ALL) NOPASSWD:ALL

Replace the obvious with the obvious, as always. Be extra careful to avoid typographical errors. Then, you’ll save the file. As we’re using nano, the process to save the file is pressing CTRL + X, then Y, and then ENTER – and that should save the file. Congrats, you now know how to add a user to the ‘sudoers’ file.

Closure:

Well, it’s another article. As I mentioned, there are legitimate reasons to add a user to the sudoers file. There are also legitimate reasons for not doing so. It depends on you and your circumstances – and your computing goals are your own. This is Linux. We can do what we want!

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: Update A Single Package In Ubuntu

Today’s article should be short because it’s late in the evening and I have decided to write about how to update a single package in Ubuntu. It’s an easy topic to write about, as there are really just a couple of choices. It shouldn’t be complicated and, for the most part.

First, let me state this…

I firmly believe that you should keep everything updated and updated the minute the update is available.

HOWEVER…

That assumes a perfect world. We do not live in a perfect world. We live in the real world. Because of this, people delay updates for various reasons. The biggest delay I can think of at this hour of the night is the delays added in the business world.

Rather than push an update to production, they’ll run it through testing first. It can take quite a while before an update makes it into production.

The reality is that many of our updates are security updates. As a byproduct of their update policy, at any given time they’re running insecure software. I understand why they’d do this. They don’t want things to break. They certainly don’t want public-facing things to break.

Again, I can understand why regular people follow a similar process. They’ll wait and watch to see if the updates cause problems for other people. But, that’s like waiting for the first person to jump in the river to see if the water is cold.

In all my years of using Linux, I’ve had updates bork the system fewer times than I have fingers on one hand. I’ve had updates bork the system so completely that it hoses everything exactly zero times. As in, not once was I screwed over by an update that really did any damage.

But…

Again, I can understand those who would rather be cautious.

This article is for you. It’s for you people who want to update a single package in Ubuntu. It’s for those people who do what they must in order to maintain a stable system.

This isn’t just applicable to Ubuntu. I tend to use Lubuntu and, as such, am a fan. So, I used Ubuntu in the headline. This applies equally to Debian, Mint, and other Ubuntu derivatives. It should even work in derivatives of derivatives. It’s pretty basic stuff.

Update A Single Package In Ubuntu:

So, you might be able to do this with a GUI. I don’t actually know and I didn’t test to see if there was a way to do so graphically. Check your software manager while the rest of us open a terminal. You can (more often than not) open your default terminal by pressing CTRL + ALT + T.

With your terminal now open, you need an application to update. If you’re a good netizen, you hopefully don’t have many upgrades available. You can check and see by running this command:

sudo apt update

1	sudo apt update

You can then get a list of applications that can be updated, assuming there’s an application that can be updated, with the following command:

sudo apt list --upgradeable

1	sudo apt list --upgradeable

The next step is to use one of the following two commands to update a single package in Ubuntu (neither of which are all that difficult):

sudo apt install <package_name>

1	sudo apt install <package_name>

Yes, that looks like it’s going to install a new application, but you substitute the <package_name> with the package name that you want to update in Ubuntu. The ‘install’ will happily upgrade to the next passage.

The next one is bit more jargony. Jargon-y? Maybe? It’s more complicated looking (but easy enough to memorize). So, if you want to update a single package in Ubuntu, this too should also do the trick:

sudo apt-get --only-upgrade install <package_name>

1	sudo apt-get --only-upgrade install <package_name>

Once again, you replace the obvious with the obvious. Just doing so would help you sort out how to update a single package in Ubuntu. Either of these commands should work, so you do have a choice.

Closure:

As I said, it’s not going to be all that difficult to update a single package in Ubuntu. You have a choice in commands. While I think it’s best to avoid all update delays, I do understand why you might want to be more cautious.

I go full blast at updates, but I’ve lately been a bit slow about major upgrades. In my case it’s a bandwidth issue. I had one box running like Linux Mint 20 or something like that…

Wait, it still says 21 is the version – but I’m quite literally nearing the end of the upgrade process. That may have already changed. I was so far behind that I needed more than 4 GB worth of downloads. When I’m done we’ll have an OS that’s missing almost all the stuff I installed on top of it!

It can sure be a pain in the butt. Alas, as least I’m not trying to update a single package in Ubuntu!

Some Opinions (News?) About Purism.

Today’s article isn’t like a regular article, it’s just some news about Purism. There’s not going to be much written about this company by me, as I’m not wanting to get sued by angry people. I’m mostly going to give you some information and then share a video. With that information, you’ll be free to make your own choices.

Let’s start with the basics…

I have been paying a little bit of attention to Purism for quite some time. I have considered giving them money, but there were already enough complaints that I never felt comfortable doing that.

Purism SPC, the company, is located in San Francisco, California. They have been around since 2014 and they sell products that are based on ‘opensource’, hardware such as laptops and phones.

Their site can be found at https://puri.sm/

Purism claim to be interested in protecting your privacy and liberties, by using open-source software. There are lots of thoughts about this.

I have seen a few people mention this company lately, as though they were interested in their products. I feel an obligation to inform, thus this news article about Purism.

I will not be offering my opinions on the matter. As much as free speech exists in my country, I don’t really feel like spending money on legal fees and I don’t want to deal with a cease-and-desist notice that tells me to take the site down.

What I am going to do is share a video with you.

Warning, this video uses adult language – but provides sources for their claims. I would suggest watching this video if you’re interested in Purism products.

Now, you take that information and do with it what you will. You can view a bunch of old/current complaints at the Purism Subreddit. There are also a number of topics over on HackerNews but I don’t have links to those. I’m not trying to do an expose, I’m trying to help people make wise choices. This means doing your research – and real research.

Closure:

My opinions are my own, though I’m sure it’s okay to say that I do not now own any Purism products and I do not intend to buy any in the near future. This is simply one of many videos, articles, and comment chains that finally made me realize that I should probably share this with others – as we don’t all dive deep into things prior to making a purchase decision.

What you do with this information is up to you.

I will further suggest that any comments on this matter should be left here. It’s well known that I share my articles elsewhere but I don’t know if Purism is lawsuit happy and I don’t think I’d like to put other sites at risk. I’m sure it’s fine, but we’ll see…

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:

who -u

who -u

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:

who -u | awk '{print $1, $6}'

1	who -u \| awk '{print $1, $6}'

This will give you an output similar to this:

$ who -u | awk '{print $1, $6}'
kgiii 2253
test_user 174676

$ who -u | awk '{print $1, $6}'

kgiii 2253

test_user 174676

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

sudo kill -HUP <PID>

1	sudo kill -HUP <PID>

Or, for example:

sudo kill -HUP 174676

1	sudo kill -HUP 174676

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:

sudo kill -9 <PID>

1	sudo kill -9 <PID>

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:

sudo kill -HUP <PID> <PID> <PID>

1	sudo kill -HUP <PID> <PID> <PID>

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!

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:

sudo nano /etc/ssh/ssh_config

1	sudo nano /etc/ssh/ssh_config

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:

ClientAliveInterval <seconds>
ClientAliveCountMax <number_of_checks>

1 2	ClientAliveInterval <seconds> ClientAliveCountMax <number_of_checks>

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:

ClientAliveInterval 300
ClientAliveCountMax 5

1 2	ClientAliveInterval 300 ClientAliveCountMax 5

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:

systemctl restart sshd

1	systemctl restart sshd

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

service sshd restart

1	service sshd restart

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