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.

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

Let’s Take A Look At Logged In Users

Today is a good day to learn how to take a look at logged in users. The vast majority of my readers are desktop users, so you can mostly skip this article. On the other hand, when you take a look at logged in users, you might find users you didn’t know were logged in and discover a problem like unknown users.

Yeah, most of you – including me at the moment (which makes it difficult to do things like take useful screenshots) are using Linux (mostly) as a single user. You have a user and you login to that user account when you start your system up.

While you do have other system-configured users, you don’t generally login as those users. As such, you probably spend very little time thinking about the users you have. Those system users aren’t generally logged in but are there for permissions purposes, so they’re out of mind for most of us.

Well, for the rest of you, you can use this article to learn how look logged in users – even getting a glimpse at what they’re doing. I mentioned some difficulty in taking screenshots, so I’ll provide you with just one. Cherish it, as it’s the only one you’re getting!

Here it is:

looking at other users
See? I’ll reference some of this below, in the article itself. I might as well…

Have A Look At Logged In Users:

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.

As you can see from the image above you can see all the logged in users with the first command. The following command will list them:

You’ll see the same thing, with a bit more information, when you use the following command:

Now, in the image above, you can see where I used it once and then ran it again. What you don’t see is that, in between those two commands, I opened up another TTY and logged in again as ‘kgiii’. If you want to replicate that, just press CTRL + ALT, then F3 to F6, and login at the prompt with any user(s) you happen to have.

Finally, you can get a look at what they’re doing – like one has a desktop session open and two of those login instances just have bash sessions open in TTY sessions. To do that,  you just use:

That should be easy enough for you to remember! By the way, if you did login as an additional TTY instance, run ‘users‘ again and you’ll see the output for that command has changed accordingly. The command’s output will may also give you a good idea about how long the system has been up and what the system resources are like.

Closure:

There you have it. You have learned how to have a look at logged in users so that you can have an idea of what’s going on with your system. If you spot a user you don’t recognize, that might be indicative of a problem. If you spot a user you don’t recognize, you’ll need to do some more investigating. By the way, if you have ‘finger’ installed you can always run ‘finger <username>‘.

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: 1 Average: 5]

Install And Secure MariaDB In Ubuntu

I’ve recently purchased a couple of new VPSes (spelling?) and so today’s article is about how you install and secure MariaDB. As mentioned before, some articles are just going to be me scratching my own itch. In this case, I have a couple of virtual private servers that are doing nothing more than costing me money. I might as well put them to good use.

So, what is MariaDB? It’s a database management system that’s a fork of MySQL. Oracle purchased Sun Microsystems in early 2010 and MySQL went with it. Quite a few people didn’t trust Oracle’s stewardship of MySQL, they were already known for their own database management system, and so MariaDB was born.

MariaDB is actually a fork of MySQL. MariaDB is also permissively licensed, while the newer MySQL has an enterprise version with proprietary code in it. MariaDB is completely open and works just fine under a number of FOSS licenses.

MariaDB is just as fast, and faster in some operations. It supports the native languages used with databases. It’s well supported with a vast number of installs running some of the largest databases on the planet. MariaDB is one of many MySQL forks, which is to be expected. After all, MySQL was the first of its kinda – a free database management system that was released at a key  point (mid 1990s) of Internet development.

In my observation, and despite all its goodness, MariaDB a testament to exactly how much people dislike and don’t trust Oracle! So, then, why not…

Install And Secure MariaDB:

As this is server related, you’re likely to be doing this in a terminal and you’re likely to be using SSH to do so. So, I’m going to assume you already have a terminal open, saving us some time.

Make sure you’re fully updated before attempting this, so:

Now, we’ll go about installing MariaDB. It’s trivial, just run:

That’ll take a minute and, when done, you can verify that the MariaDB service is up and running properly. That needs this command:

MariaDB should be installed and running – but it’s woefully insecure. In order to secure the MariaDB installation, you will want to run the following command:

It’s going to first ask you for your root password. You’ll enter your default root (sudo) password. One of the questions will let you assign a different password for MariaDB and it’s strongly recommended that you do so. For the other few questions, you can read them or you can just answer yes to all of them, as all of them are the best choices for securing your databases.

That’s actually all there is to it. You’ve learned to install and secure MariaDB. It’s one of the many steps you might take if you wanted to set up your own server, so be careful when you’re doing so and opt for the best practices.

Closure:

There you have it! It’s another article, this one tells you how to install and secure MariaDB. In some cases, rare cases indeed, you might want to open it up to connections outside of localhost. If you do that, be sure to open up the correct port in the firewall. Other than that, you’re good to go.

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: 1 Average: 5]

Guest Article: Kickstart Vol. III

Today is the third guest article in a row, and is one more article about Kickstart. There will be more Kickstart articles, but we’ll release those in time. This is the third one in a row, so we’ll try to mix it up a bit.

By now, we should all have at least a little familiarity with Kickstart. Frankly, I’ve still not had a chance to use it – but it does seem like it’d be fun to play around with it. If I were an admin of anything major, I’d definitely look to Kickstart as a solution. Again, if you read this on day one, be sure to check back later as the author may suggest some edits.

See the previous articles here:

Guest Article: Kickstart Vol. I
Guest Article: Kickstart Vol. II

Kickstart Vol. III

Now we need to create a menu for your Kickstart, so you can select which OS you want to install.

Now edit a new file named grub.cfg. It must be named grub.cfg. Here is an example of what it should look like.

The set-default lets you pick which is the default install, it starts at zero, so the options here would be 0, 1 and 2.

Note the IP address of my Kickstart server is here, the path to my extracted iso directory is here, and the location of my boot kernels is here.You can change all of these to fit your needs.

Now we need the actual anaconda-kickstart.cfg files, this is what actually does all the work.The location of these, is set in the grub.cfg file above. You will want these to be in the extracted iso directory, but not in the “dvd” sub-directory.

Here is an example of what one of these would look like. This one is fairly basic.

Again you see the IP address of my kickstart server here, you see the location of my extracted iso files here.Now there are a few things you will need to know in advance.

What I typically do, is install the OS from a USB the first time.In the case of fedora/redhat/CentOS there will be a file at /root/anaconda.cfg. You can copy this file as a starting template for your kickstart of this OS.

(Yes I am re-naming the file here.)

Also you will need the password has strings for your users.

(Or whatever user name you use.)

You will need to know the name of the LAN interface, and you will need to know the size of your hard, and how big the partitions should be.All of these things will be in your anaconda.cfg file

Now change and edit a few things in your fed35srv/fed35.cfg file now.

Change the graphical install to..testskipx This uses a cli interface, not a GUI when installing.

Change the url line to the location of your extracted iso directory in your web server. Note you don’t put the full path, only the path from your webroot.

I like to turn off seLinux, but you can delete that line if you like.

Change your timezone to whatever is appropriate for you.

Using the two example user lines above (those aren’t real hashes, I just typed a bunch of random characters to simulate what it looks like). Edit the user lines to be whatever your values are.

That’s it, you’re don! Now boot your test computer on the kickstart network. A Kickstart menu should appear. Select the appropriate OS.

I’ve found this usually works best with a few settings on the test computer. CSM should be disabled. Network stack should be enabled. Some UEFI settings let you pick PXEboot IPv4 as a boot option. This is preferred. I’ve found it works best with a freshly formatted hard-drive, that way it doesn’t try to boot into the installed OS.

Good luck!

Closure:

And there you have it! You have a guest article, from dos2unix, about Kickstart. There are now three of them and there are a couple of others sitting in the potential queue. We’ll get to them. These few days off have been a very welcomed respite!

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: 3 Average: 5]

Guest Article: Kickstart Vol. II

Today’s guest article is a continuation of the Kickstart theme. The first Kickstart article can be found here. Thanks goes out to dos2unix from the Linux.org forums.

I should mention again that I don’t actually know anything about Kickstart, other than what I’ve read in these articles. I’m extremely grateful, but you may want to check back a few times to ensure all the editing is complete!

Kickstart Vol. II:

Now that we have your web server, dhcp, and tftp server configured, we will need to enable the firewall for them.

On Fedora it looks like this:

Now we need to extract the iso files you have handy (you did already download these, right?) I should have mentioned you will need the “server” version of these iso’s. There is a way to make the workstation iso’s work, but that’s for another more advanced article.

For the example here, I put everything in: 

When that gets done copying, we can add another OS’s iso if you like:

If you have more iso’s repeat the same for CentOS or Redhat or whatever you have.

Again, when it gets done copying, simply umount the iso image. I confess, I’m something of a minimalist. I like short names like pub/fed35srv. If you like long names you could have something like /public/fedora35-server/x86_64/ I’m too lazy to type all of that in all my config files.

Now we will install the boot kernels. This isn’t actually the full kernel yet, just a lite kernel with enough parts to boot the system from the network.

Just about all computers have one of two types of internal configuration systems. Legacy BIOS and UEFI. Most newer computers in the last 8 years or so,are UEFI, but there are still plenty of Legacy BIOS systems around. For the purpose of this article we will set-up for both types.

In your /var/lib/tftpboot directory, we will make two directories. One for BIOS and one for UEFI.

Technically you could rename the efi directory to something else, but the pxelinux for legacy BIOS systems is hardcoded in some files.

Now you will need to download a couple of files. I recommend using the Fedora 35 version, even if you are going to be installing Redhat or CentOS. They are newer, have more features, bug fixes, and support more hardware.

But you can use the CentOS or Rehat versions if you want to. Shim-x64, grub2-efi-x86, and grub2-efi-x64-modules. We will need to extract these rpms. You can do this in /tmp or somewhere safe.

If it says this is already installed, replace install with reinstall. These are the efi files you will need for efi based systems.

This will create 3 directies in /tmp.

You can delete these directories in /tmp if you like, you are done with them. Make sure you don’t put a leading / and actually delete /usr and /etc.

The next part depends on what iso’s you have downloaded and extracted. But hopefully you will get the idea.I am using Fedora 32, Fedora 35, and Redhat 9 as my examples. You can use whatever directory names you like.

That’s enough for this article, will add next part later.

Closure:

And there you have it, another article and this one is a guest article – just like yesterday and probably just like tomorrow. I’m extremely grateful for the respite and wish I knew more about Kickstart. I think, for future reference, I’m gonna ask that folks register and write the draft here. I think it’d streamline 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.

Smash a button!
[Total: 4 Average: 5]
Linux Tips
Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 International License.
Zoom to top!