Tips Archives • Page 55 of 66 • Linux Tips

Prevent SSH Root Login

Today’s article will tell you how, and why you’d want to, disable root login via SSH. It’s actually a brief article and approachable by even a beginner with SSH. If you have SSH enabled, then you may want to make sure to do this.

In some cases, like Ubuntu, the root account is disabled by default. That’s generally a good thing. In that case, this article may be important to you if you’ve enabled root login. This article may also be of interest for those who have changed the port SSH uses. Even if logging in as root is already disabled, it won’t hurt to disable it via SSH. Even if the port has been changed, disabling SSH root login won’t hurt.

So, why would you want to disable root login for SSH? Well, it’s a known account – meaning ‘root’ is pretty standard across the distros. An attacker already has half the information – the name of the account. It’s also an account that has the keys to the kingdom. If you have control of the root account, you have complete control of the system. This is fine if it’s your system and you with the root account, it’s less appreciated when it’s someone else that has control of your devices.

This article is actually pretty easy and is a step I suggest everyone take. What it does is it prevents root login via SSH entirely. It’s a simple step to make your computer more secure by preventing SSH root login. You can still login with other accounts and use sudo, so it’s really not limiting your ability to control the system.

Prevent SSH Root Login:

Like many other articles on this site, this one needs an open terminal. You can open your terminal with your keyboard – just press CTRL + ALT + T and your default terminal should open.

Once you have your terminal open, enter the following command:

sudo nano /etc/ssh/sshd_config

1	sudo nano /etc/ssh/sshd_config

Once that’s open, you’re looking for #PermitRootLogin no. When you find that line, you simply want to remove the # symbol. The end result should look like this:

PermitRootLogin no

1	PermitRootLogin no

In some default configurations, you may see #PermitRootLogin prohibit-password instead. If you uncomment that line, you could still login as root – you just can’t login with a password and would have to use a key like in this article about SSH keys.

In that case, when the line doesn’t exist or is changed, you can just add the line yourself. It won’t hurt anything and will still work. So, just find a blank section in the config file, add a new blank line, and then add the PermitRootLogin no like above.

Once you’re done, you need to save the file. As we’re using nano, you do that by pressing CTRL + X, then Y, and then ENTER. That should save the file with the correct name.

Finally, you will want to reload SSH. That’s easy enough, you reload SSH with the following command:

sudo systemctl reload sshd

1	sudo systemctl reload sshd

That’s it, that’s all you need to do! Once you’ve done that, and you can test it yourself. You shouldn’t be able to login to SSH with the root account, which is a pretty solid security idea. If you can’t login as root, nobody else should be able to login as root.

By the way, if you decide you want to undo this – just go back into the config file and add a # at the start of the line, save it, and restart the sshd daemon.

Closure:

That’s it. Thanks for reading yet another article! This one is pretty quick and easy, plus it will help you increase your server’s security. There really aren’t many reasons to have SSH root login enabled, and disabling it completely removes that attack vector.

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.

Guest Article: Repetitive Stress Injuries (RSIs)

We tech workers (and enthusiasts) tend to spend many hours at our desktops, performing the same physical and mechanical motions over and over again, making us susceptible to Repetitive Stress Injuries (RSIs). That’s what this article is going to be about, oddly enough. It’s a good subject to consider, for all of us.

RSIs are caused by doing the same thing, over and over again. That’s just not good for the body. There are ways to minimize the risk of injury, but the prevalent wisdom includes everything from breaks to ergonomically designed equipment.

According to this recent link, 2/3rds of all workplace injuries are repetitive stress injuries. One quote from the article that rings true is, “Today, the main causes of RSIs are manual labor, office work, and the overuse of computers, leading to injuries localized in the upper body.” (Emphasis mine.) We geeks certainly tend to fall into that category, using computers for much of our awake time, both at work and at home.

I don’t really want to give much in the way of medical advice, so I’ll say that you should spend some time looking up ways to reduce your chances of getting an RSI. They’re a pretty serious risk. To this day, I still have flair-ups in my right wrist. I wear a wrist-wrap but the flair-ups are so bad that even turning a door knob is uncomfortable. Surgery was the recommended solution, but I’ve been chopped open enough.

When I saw someone on Reddit offering to do medical articles, I asked them to write an article about RSIs. The output from that request follows below the links and disclaimer.

This article was provided by the owner, operator, and writer for “Daily Remedy“. The author of this site offers no opinion on the content of the linked site, I’m just happy to have the article about RSIs. Don’t forget that you too can write an article. A special thanks goes out to the author of this article. I hope that you readers enjoy it as much as I do.

Repetitive Stress Injuries (RSIs):

A push of a thumb, a flick of a finger, and a wrangling with a wrist – just some of the many actions we undertake when using the latest gadgets promised to improve our health.

But with the influx of these new gadgets, we enter a brave new world. In which consumer electronic devices are not defined by traditional principles of consumerism, but consumed with healthcare data – often using awkward, inconvenient gadgets to obtain such data.

Device manufacturers tout the importance of healthcare data when marketing the devices. And consumers eagerly acclimate to the lack of ergonomics when purchasing the devices. Simply put, device manufacturers often develop medical devices that are uncomfortable for consumers, who in turn accept such discomfort as acceptable practice for medical devices – all in the name of data.

But when does the discomfort of the device supersede the value of the data? – when the discomfort harms patients while using the device.

Known as repetitive stress injury (RSI), it is a medical condition that affects many office workers throughout the country. Normally ascribed as work-related overuse injuries, ostensibly from desktop computer use – be it the mouse or the keyboard – RSI is often treated with braces or work restrictions as a first line treatment.

But with healthcare growing to encompass a larger part of the economy, and more patients utilizing peripheral monitoring devices at home for chronic diseases, we will soon see a rise in new forms of RSI – coming from the medical device use itself.

In a 2019 study, continuous positive airway pressure devices, known as CPAP machines, used for patients with obstructive sleep apnea (OSA), were evaluated for device design and ergonomics. The study found many of the CPAP devices were poorly designed, incorporated little to no user feedback in device design, and were built using an antiquated engineering-centric focus of device design.

The same study, while attempting to present solutions to the problem of CPAP machine designs, acknowledged particularly unique difficulties in designing an ergonomic CPAP machines – which include engineering hurdles and psychological barriers to effective use.

Clearly there is more to effective device design in healthcare than traditional ergonomic principles. In fact, we should begin to study ergonomics in healthcare as a unique field in its own right, something I propose to call, healthcare ergonomics.

Healthcare ergonomics accounts not only for the engineering barriers that go into medical device design, but also for the psychological barriers patients face when using the device. In other words, healthcare ergonomics accounts for device use from the perspective of a consumer and that of a patient, a veritable dual identity of the end user.

Healthcare ergonomics balances the ease of use with the value of the data gleaned, further complicating device design, since the design itself is not the only consideration, but also the ability to glean the necessary data as well.

Some devices seem to have succeeded. The Apple Watch is an early test case of such success. Consumer Reports analyzing the latest iteration of Apple Watches find the device consistently excellent in various reviews.

Interestingly, the report notes the Apple Watches’ ability to optimize most mundane tasks: “But they do it by performing the routine jobs just a little better than the Series 4; notching top ratings for step counting, heart-rate tracking, and ease of use.”

Apple is known for their prowess in device design, so these reports should come as no surprise. But it is still commendable that a traditionally consumer oriented technology company could adapt to healthcare ergonomics so readily. And their ability to make such a transition should be emulated among other companies considering entering the healthcare space.

But it was not easy. Apple had more than its fair share of missteps – something the company openly acknowledges. The early versions of its heart rate monitoring and EKG (heart rhythm tracing) were wildly inaccurate. But they persisted – both in the device design and in the data gleaned – and for their persistence they are rewarded with first mover status into a healthcare market with spectacular market potential.

Apple balanced device design from the perspective of a patient and a consumer, and they weighed design with data, noting the importance of high fidelity data trends. They engaged in clinical studies with academic medical centers to study their watches. They actively sought direct feedback from early adopters to glean design improvements – in fact, every aspect of the device design centered on healthcare ergonomics.

The contrast in CPAP design and Apple Watches is worth noting for entrepreneurs and executives seeking to enter or to gain market shares in the healthcare consumerism market. To truly succeed in healthcare, you have to understand the complexities of the end user and balance design needs with data quality.

Not an easy task, and likely why few have succeeded. But the roadmap is set, and the opportunity is there for anyone enterprising enough to pursue it – the burgeoning field of healthcare ergonomics.

SOURCES:

https://www.tandfonline.com/doi/pdf/10.1080/14606925.2019.1595446
https://www.consumerreports.org/smartwatches/final-test-results-apple-watch-series-5/

Closure:

There you have it, another article in the books. This time, it was a guest article. I picked the subject because it’s important, especially for us, to be mindful of our health. As a group, we’re not the most healthy of people, and adding an RSI to the list of our ailments isn’t a good idea. Trust me, you don’t want carpal tunnel.

So, take care of yourself. Read up on your devices and learn how to use them safely. Read up on best-practices so that you can try to minimize your risks. Even if you feel good now, that doesn’t mean you will always feel good and healthy.

How To: Find Out Which Kernel Version You’re Using

The Linux kernel‘s progress is marked by versioning, and this article tells you how to find out which kernel version you’re using. There are all sorts of ways to do this, but this article is going to just cover a few of them.

You might want to know which kernel version you’re using for when you ask for support. It may be that your hardware is best (or only) supported after or before a certain kernel. It may be that you want to know which kernel you’re using because you want to upgrade or downgrade the kernel.

For example, I recently didn’t want to switch to the new kernel. I saw that there was a kernel update, learned which kernel version I was now using, and promptly decided to return to an older LTS kernel. Yes, different kernel versions will have different support lengths. I opted for a more stable and consistent kernel as none of my hardware required a newer kernel.

There are any number of reasons why you’d want to know which kernel version you’re using. And, as stated, there are any number of ways to get that information. This article only covers some of them.

Find Out Which Kernel Version You’re Using:

This article will only show you how to determine which kernel version you’re using with the terminal. Of course, this means you need an open terminal. You can do so with your keyboard – just press CTRL + ALT + T and your default terminal should open.

With your terminal open, you can try:

uname -r

uname -r

The information is also contained in the output of ‘hostnamectl’, so working with grep you’d have this command:

hostnamectl | grep Kernel

1	hostnamectl \| grep Kernel

You can also use cat on/proc/version in a command that looks like:

cat /proc/version

1	cat /proc/version

If you have screenfetch or neofetch installed, the output contains the kernel version that you’re using. An output from those would look kinda like this:

neofetch in action — Neofetch in action, showing the kernel version number. See? It’s all over the place!

So, there are any number of ways to find which kernel version you’re using. There are surely other ways to find the kernel version, so feel free to leave a comment letting us know how you find your kernel version.

By the way, if you’re having problem with your current kernel, your distro probably has at least the previous kernel installed and you can use that as a fallback. Even if it automatically deletes old kernels, it usually leaves at least one older kernel as a way to recover should the proverbial poop hit the aerator.

Closure:

See? That wasn’t so painful! It’s another article that’s said and done. We’re getting closer to the halfway point, but I’m legitimately having fun getting my notes online. I admit, I pretty gleefully monitor the increasing (or sometimes consistent) traffic. It makes me happy to know my notes are helping.

Get Hardware Info With ‘dmidecode’

Today’s article will explain how to use dmidecode to get information about your hardware. The command is a little different than most, as it actually checks your system’s BIOS and reports that information.

Yes, you read that correctly. This dmidecode command checks the BIOS and reports that information. There are times when the BIOS reports different hardware than other tools, so it’s a good idea to have some knowledge about your hardware to begin with.

Anyhow, I could sit here and try to explain dmidecode, or I could just use their description – which is better than I could do.

dmidecode is a tool for dumping a computer’s DMI (some say SMBIOS ) table contents in a human-readable format. This table contains a description of the system’s hardware components, as well as other useful pieces of information such as serial numbers and BIOS revision. Thanks to this table, you can retrieve this information without having to probe for the actual hardware. While this is a good point in terms of report speed and safeness, this also makes the presented information possibly unreliable.

As you can see, it’s a pretty interesting tool. It’s almost certainly installed for you by default. If it isn’t and you’re using a major distribution, check your system’s repos and it’ll be in there. It’s a pretty neat tool and one that you can use regularly, even though there are other tools that tell you about your hardware.

Using dmidecode:

This article requires an open terminal. Open one with your keyboard by pressing CTRL + ALT + T and your default terminal should open.

Many distros have dmidecode installed by default. If not, you’ll need to install it with your systems software installer. It’s bound to be available for any major distro. Now…

There’s a whole lot to this dmidecode thing, so we’re going to rely on the man page quite a bit. You’re encouraged to crack open a second terminal in which to run man dmidecode. That’ll help!

The first way to run dmidecode is with the -s flag, where you’ll use a name. In your first terminal, type the following to get the BIOS vendor’s name:

sudo dmidecode -s bios-vendor

1	sudo dmidecode -s bios-vendor

That’s the first (and pretty handy) way to run this command. Some of these commands will even give you information that helps you not have to open the case. That one helps you find the BIOS vendor’s name without having to reboot and check the BIOS yourself.

There are quite a number of options (names) that follow the -s flag, such as baseboard-serial-number, processor-family, or even chassis-serial-number. There’s a ton of them – so switch to the terminal with the open man page and check the text next to the -s flag for more information.

The other way to run dmidecode is with the -t flag. In this usage, you’ll need to know the corresponding number to the information you want. That’s okay, you don’t need to memorize them, as I explain below. The basic command is:

sudo dmidecode -t <number>

1	sudo dmidecode -t <number>

The number should correspond to the information you want. In the terminal with the open man page, you can scroll down to see your options. You’ll see that #13 is about the BIOS language, so command would look like:

$ sudo dmidecode -t 13

1	$ sudo dmidecode -t 13

The output would look similar to this:

dmidecode showing bios language — There’s some cruft in the output, but it is indeed the BIOS language.

You can refer to the above-mentioned man page, memorize them, or use a cheat sheet (if you plan on running the command frequently). I assume the project keeps things updated, so checking the man page at their GitHub would be the most correct source.

Either way, you will see that you will need to know both ways of running dmidecode in order to make the most out of dmidecode. You’ll need to be both fluent with the keywords and with the DMI Types, should you want to make the most out of this application – but you don’t have to memorize the entire man page.

Closure:

There you have it, another article is in the books! This time, it’s about dmidecode – a valuable tool to add to your growing arsenal of tools. It’ll save some time if you end up needing it, so you might as well learn about it before you need it.

It’s Time To Learn A Little About The ‘head’ Command

Today’s article is about the ‘head’ command. The head command is a tool for viewing a file’s contents (or piped data), starting from the top. There’s not a whole lot to the command, and this will make be a pretty short article that’s fit for a beginner.

The head command has been with us since the heady days of Unix (See what I did there?) and is still a useful command today. In fact, the man page defines it like this:

head – output the first part of files

As you can guess, it does exactly what it says on the tin. There are any number of circumstances when you might want to use it, but I often use it when I don’t remember the exact filename I’m after and just want to see the first few lines of text as a reminder. There are better uses.

Anyhow, there’s not a whole lot to it, but I’ll show you the basics. Like we did recently, let’s see if we can all get started on the same page. So, open your terminal and enter the following:

cd Downloads
wget https://linux-tips.us/files/rnd-num.txt

1 2	cd Downloads wget https://linux-tips.us/files/rnd-num.txt

Doing that will put you in the Downloads directory and will download a text file (it’s perfectly harmless) and it means we are all working with the same settings. You do not need to do this, but it could help.

About The ‘head’ Command:

Seeing as you’ve already got the terminal open, and that you figured it out without me having to repeat it like I do in almost every article, we’ll just jump right into the first command.

head rnd-num.txt

1	head rnd-num.txt

That should output the first ten lines of the rnd-num.txt file, looking something like this:

head in action — If you used the rnd-num.txt, your output should be the same. Pretty neat, huh?

That’s the first ten lines from the rnd-num.txt file or, in other words, the head of the file has been outputted to the terminal. This has a number of uses, including the pipe. You can easily pipe it to another command. It’d look something like this:

head rnd-num.txt | cat > test.txt

1	head rnd-num.txt \| cat > test.txt

That’s not all that head can do, it can output a specified number of lines. To do that, you use the -n flag. It looks like this:

head -n 5 rnd-num.txt

1	head -n 5 rnd-num.txt

You can also use the -c flag to show the first x-number of bytes in a file. That’s not very complicated. In this case, we’ll look at the first 25 bytes.

head -c 25 rnd-num.txt

1	head -c 25 rnd-num.txt

You’ll find the output looks pretty similar to the output from the previous head command. You can even work with multiple files and the head command will handle them easily. If you’re going to use multiple files, you should use the -v flag.

head -v rnd-num.txt test.txt

1	head -v rnd-num.txt test.txt

It’ll helpfully preface the start of each file with the name of the file. In this case, the first line of the output would look like this:

head with multiple files — See? It’ll handily list the filename before listing the output.

See? Pretty helpful!

As shown in the image, you can easily deal with multiple files and whatnot, but there’s really not much more to be done with the head command. If you’re curious, you can also enter man head to get more usage information.

Closure:

Yup… There’s another article. This is about the head command, a command that’s not used often but worth having in your toolbox. If you use it more often, feel free to leave a comment explaining what you do with it.