Chapter 5. Connecting to Red Hat Enterprise Linux 8

The following topics are covered in this chapter:

• Working on Local Consoles

• Using SSH and Related Utilities

The following RHCSA exam objectives are covered in this chapter:

• Access remote systems using SSH

• Log in and switch users in multiuser targets

• Boot, reboot, and shut down a system normally

• Securely transfer files between systems

• Configure key-based authentication for SSH

You have already learned how to log in on Linux from a graphical environment. In this chapter, you learn about some other methods to access a Linux shell and start working. You learn how to work from local consoles and from Secure Shell (SSH) to connect to Linux. You also learn how to perform some basic tasks from these environments.

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz allows you to assess whether you should read this entire chapter thoroughly or jump to the “Exam Preparation Tasks” section. If you are in doubt about your answers to these questions or your own assessment of your knowledge of the topics, read the entire chapter. Table 5-1 lists the major headings in this chapter and their corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes and ‘Review Questions.’”

Foundation Topics Section	Questions
Working on Local Consoles	1–6
Using SSH and Related Utilities	7–10

1. Which is the correct term for the description here?

“Used to refer to the physical screen you are currently looking at as a user”

a. Terminal

b. Console

c. Shell

d. Interface

2. Which is the correct term for the description here?

“The environment from which a shell is used where users can enter their commands”

a. Terminal

b. Console

c. Shell

d. Interface

3. Which is the correct term for the description here?

“The environment that offers a command line on which users type the commands they want to use”

a. Terminal

b. Console

c. Shell

d. Interface

4. Which device file is associated with the virtual console that is opened after using the Alt-F6 key sequence?

a. /dev/console6

b. /dev/tty6

c. /dev/vty6

d. /dev/pts/6

5. Which of the following methods will open a pseudo terminal device? (Choose two.)

a. Log in using an SSH session

b. Press Alt-F2 to open a new nongraphical login

c. Right-click the graphical desktop and select Open in Terminal

d. Enter your username and password on a nongraphical console

6. Sometimes a server reboot may be necessary to accomplish a task. Which of the following is not typically one of them?

a. To recover from serious problems such as server hangs and kernel panics

b. To apply kernel updates

c. To apply changes to kernel modules that are being used currently and therefore cannot be reloaded easily

d. To apply changes to the network configuration

7. Which of the following is true about remote access to Linux servers from a Windows environment?

a. Open a shell terminal on Windows and type ssh to access Linux servers remotely. The ssh command is available as a default part of the Windows operating system.

b. Configure Remote Access on Windows if you want to access Linux servers running the sshd process.

c. Install the PuTTY program on Windows to access sshd services on Linux from Windows.

d. You cannot remotely access Linux machines from Windows.

8. What is the name of the file in which the public key fingerprint of the SSH servers you have connected to in the past are stored?

a. /etc/ssh/remote_hosts

b. /etc/ssh/known_hosts

c. ~/.ssh/remote_hosts

d. ~/.ssh/known_hosts

9. To allow graphical applications to be used through an SSH session, you can set a parameter in the /etc/ssh/ssh_config file. Using this parameter makes it unnecessary to use the -X command-line option each time an SSH session is initiated. Which of the following parameters should be used?

a. Host *

b. TunnelX11 yes

c. ForwardX11 yes

d. Xclient yes

10. Which of the following statements about key-based SSH authentication is true?

a. After creating the key pair, you need to copy the private key to the remote server.

b. Use scp to copy the public key to the remote server.

c. Use ssh-copy-id to copy the public key to the remote server.

d. Use ssh-keygen on the server to generate a key pair that matches the client keys.

Foundation Topics

Working on Local Consoles

You have already learned how to log in on Linux by using a graphical console. In this section, you learn some more about the possibilities you have while working from either a graphical Linux console or a text-based Linux console.

Before we get into details, it makes sense to highlight the difference between the words console and terminal. In this book, I follow the common notion of a console as the environment the user is looking at. That means that the console is basically what you see when you are looking at your computer screen.

A terminal is an environment that is opened on the console and provides access to a text shell, which is the command-line environment that can be used to type commands. A terminal can be offered through a window while using a graphical console, but it can also be opened as the only thing that you see in a textual console. This means that in a textual environment, the words console and terminal are more or less equivalent. In a graphical environment, they are not. Think of it like this: You can have multiple terminals open on a console, but you cannot have multiple consoles open in one terminal.

Logging In to a Local Console

Roughly, there are two ways to make yourself known to a Linux server. Sometimes you just sit at the Linux console and interactively log in from the login prompt that is presented. In other cases, a remote connection is established. The second part of this chapter is about logging in from a remote session; in this part, you learn how to work from a local console.

If a Linux server boots with a graphical environment (the so-called graphical target), you see a login prompt on which a username and a field in which to enter a password can be entered. Many Linux servers do not use a graphical environment at all, though, and just present a text-based console, as shown in Figure 5-1.

To log in from a text console, you need to know which user account you should use. A user root is always available, but using this account to do your work is often not a good idea; the user root has no limitations to access the system and can therefore do a lot of damage. A small mistake can have a huge impact. Typically, it is a better idea to log in as one of the locally defined users, and there are many reasons to do so, including the following:

• It will make it more difficult to make critical errors.

• On many occasions, you will not need root permissions anyway.

• If you only allow access to normal users and not to root, it will force an attacker to guess three different things: the name of that specific user, the password of that user, and the root password.

• If you do need root access anyway, you can use the su - command from the local user environment to open a root shell. This opens one root shell only, while you will still be an ordinary user in all other parts of your current session.

• Use sudo to configure specific administration tasks for specific users only. See Chapter 6, “User and Group Management,” for more information.

Switching Between Terminals in a Graphical Environment

When working in a graphical environment, it is relatively easy to open several different working environments, such as different terminal windows in which you can work from a shell. In the upper-left part of the graphical interface, click Activities, and in the Search bar that appears, type term, which presents an icon to open a terminal. Because terminals are opened as a subshell, you do not have to log in to each terminal again, and will get access as the same user account that was originally used to log in to the graphical environment (see Figure 5-2).

Working from a graphical environment is convenient. As an administrator, you can open several terminal windows, and in each terminal window you can use the su - command to open a shell in which you can work with a different user identity. This allows you to easily test features and see the results of these tests immediately. Exercise 5-1 guides you through a common scenario where you can do this and see how testing things from one terminal window while monitoring from another terminal window can be convenient.

Exercise 5-1 Working from Several Terminal Windows Simultaneously

1. Start your computer and make sure to log in as a non-root user account from the graphical login window that is presented. You should have a local user with the name student and the password password that you can use for this purpose.

2. Click Activities, and type term. Next, click the terminal icon to open a new terminal window.

3. Repeat step 2 so that you have two terminal windows that are open simultaneously.

4. From one of the terminal windows, type the command su - and enter the password of the root user. Then, type tail -f /var/log/secure. This opens a trace on the file /var/log/secure, where you can monitor security events in real time.

5. From the other terminal windows, type su -. When asked for a password, you normally enter the password for the user root. Enter a wrong password.

6. Now look at the terminal where the trace on /var/log/secure is still open. You will see that an error message has been written to this file.

7. Press Ctrl-C to close the tail -f session on the /var/log/secure file.

Working with Multiple Terminals in a Nongraphical Environment

In the previous section, you learned how to work with multiple terminals in a graphical environment. This is relatively easy because you just have to open a new terminal window. In a nongraphical environment, you only have one terminal interface that is available and that makes working in different user shell environments a bit more difficult.

To offer an option that makes working from several consoles on the same server possible, Linux uses the concept of a virtual terminal. This feature allows you to open six different terminal windows from the same console at the same time and use key sequences to navigate between them. To open these terminal windows, you can use the key sequences Alt-F1 through Alt-F6. The following virtual consoles are available:

• F1: Gives access to the GNOME Display Manager (GDM) graphical login

• F2: Provides access to the current graphical console

• F3: Gives access back to the current graphical session

• F4–F6: Gives access to nongraphical consoles

Of these virtual consoles, the first one is used as the default console. It is commonly known as the virtual console tty1, and it has a corresponding device file in the /dev directory that has the name /dev/tty1. The other virtual consoles also have corresponding device files, which are numbered /dev/tty1 through /dev/tty6.

When working from a graphical environment, it is also possible to open different virtual consoles. Because the combinations between the Alt key and the Function keys typically already have a meaning in the graphical environment, you need to use Ctrl-Alt-Function key instead. So, do not use Alt-F4 to open /dev/tty4 from a graphical environment, but instead use Ctrl-Alt-F4. To get back to the graphical console, you can use the Alt-F3 key sequence. The Alt-F6 and Ctrl-Alt-F6 key sequences are essentially the same. It is important to use the Ctrl key as well when going from a GUI to a text environment. To go back from the text environment to the GUI environment, using the Ctrl key is optional.

Understanding Pseudo Terminal Devices

Every terminal used in a Linux environment has a device file associated with it. You’ve just learned that terminals that are started in a nongraphical environment are typically referred to through the devices /dev/tty1 through /dev/tty6.

For terminal windows that are started from a graphical environment, pseudo terminals are started. These pseudo terminals are referred to using numbers in the /dev/pts directory. So, the first terminal window that is started from a graphical environment appears as /dev/pts/1, the second terminal windows appears as /dev/pts/2, and so on. In Exercise 5-2, you learn how to work with these pseudo terminal devices and see which user is active on which pseudo terminal.

At this point, you know how to work with the console, terminals, virtual terminals, and pseudo terminals. In the section “Using SSH and Related Utilities” later in this chapter, you use SSH to open terminal sessions to your server. These sessions show as pseudo terminals as well.

Booting, Rebooting, and Shutting Down Systems

As an administrator of a Linux server, you occasionally have to reboot the Linux server. Rebooting a server is not often a requirement, but it can make your work a lot easier because it will make sure that all processes and tasks that were running on your server have re-read their configurations and initialized properly.

For an administrator who really knows Linux very thoroughly, rebooting a server is seldom necessary. Experienced administrators can often trigger the right parameter to force a process to reread its configurations. There are some scenarios, though, in which even experienced Linux administrators have to reboot:

• To recover from serious problems such as server hangs and kernel panics

• To apply kernel updates

• To apply changes to kernel modules that are being used currently and therefore cannot be reloaded easily

When a server is rebooted, all processes that are running need to shut down properly. If the server is just stopped by pulling the power plug, much data will typically be lost. That is because processes that have written data do not typically write that data directly to disk, but instead store it in memory buffers (cache) from where it is committed to disk when it is convenient for the operating system.

To issue a proper reboot, the systemd process has to be alerted. The systemd process is the first process that was started when the server was started, and it is responsible for managing all other processes, directly or indirectly. As a result, on system reboots or halts, the systemd process needs to make sure that all these processes are stopped. To tell the systemd process this has to happen, a few commands can be used:

• systemctl reboot or reboot

• systemctl halt or halt

• systemctl poweroff or poweroff

When stopping a machine, you can use the systemctl halt command or the systemctl poweroff command. The difference between these two commands is that the systemctl poweroff command talks to power management on the machine to shut off power on the machine. This often does not happen when using systemctl halt.

Using SSH and Related Utilities

In the previous sections in this chapter, you learned how to access a terminal if you have direct access to the server console. Many administrators work with servers that are not physically accessible. To manage these servers, Secure Shell (SSH) is normally used. In this section, you learn how to work with SSH.

On modern Linux distributions, Secure Shell is the common method to gain access to other machines over the network. In SSH, cryptography is used to ensure that you can be sure that you are connecting to the intended server. Also, traffic is encrypted while transmitted.

Accessing Remote Systems Using SSH

To access a server using SSH, two components are needed. On the remote server that you want to access, the sshd service must be running and offering services at port 22, and it should not be blocked by the firewall. After installation, Red Hat Enterprise Linux starts the sshd process automatically, and by default it is not blocked by the firewall.

If the SSH port is open, you can access it using the ssh command from the command line. The ssh command by default tries to reach the sshd process on the server port 22. If you have configured the sshd process to offer its services on a different port, use ssh -p followed by the port number you want to connect to.

The ssh command is available on all Linux distributions, and on Apple Mac computers as well, where it can be launched from a Mac terminal.

If you have a Windows version that does not have the Windows subsystem for Linux, the ssh command is not a native part of the Windows operating system. If you want to access Linux servers through SSH from a Windows computer, you need to install an SSH client like PuTTY on Windows. From PuTTY, different types of remote sessions can be established with Linux machines. Alternative SSH clients for Windows are available as well, such as MobaXterm, KiTTY, mRemoteNG, Bitvise, and Xshell.

Accessing another Linux machine from a Linux terminal is relatively easy. Just type ssh followed by the name of the other Linux machine. After connecting, you will be prompted for a password if a default configuration is used. This is the password of a user account with the same name of your current user account, but who should exist on the remote machine.

When remotely connecting to a Linux server, the SSH client tries to do that as the user account you are currently logged in with on the local machine. If you want to connect using a different user account, you can specify the name of this user on the command line, in the user@server format. If, for instance, you want to establish an SSH session as user root to a remote server, type ssh root@remoteserver. An alternative way of specifying the user account is by using the option -l username. So, ssh remoteserver -l root will also try to establish a root session to the remote server. In Exercise 5-3, you learn how to log in to a remote server using SSH.

[root@server1 ~]# ssh 192.168.4.220 -l root
The authenticity of host '192.168.4.220 (<no hostip for proxy
command>)' can't be established.
ECDSA key fingerprint is 35:64:36:f8:ac:4f:8a:94:aa:6e:4b:85:ed:76:0a:eb.
Are you sure you want to continue connecting (yes/no)?

The security message is displayed in Example 5-1 because the remote server has never been contacted before and therefore there is no way to verify the identity of the remote server. After connecting to the remote server, a public key fingerprint is stored in the file ~/.ssh/known_hosts.

The next time you connect to the same server, this fingerprint is checked with the encryption key that was sent over by the remote server to initialize contact. If the fingerprint matches, you will not see this message anymore.

In some cases, the remote host key fingerprint does not match the key fingerprint that is stored locally. That is a potentially dangerous situation. Instead of being connected to the intended server, you might be connected to the server of an evildoer. It does, however, also happen if you are connecting to an IP address that you have been connected to before but that is now in use by a different server. In that case, you just have to remove the key fingerprint from the ~/.ssh/known_hosts file on the client computer. You can easily do so, using sed. For instance, use sed -i -e '25d' ~/.ssh/known_hosts to remove line 25 from the known_hosts file (assuming that is the line containing the erroneous key).

Using Graphical Applications in an SSH Environment

From an SSH session, by default you cannot start graphical applications. That is because of security; a remote host cannot display screens on your computer without specific permission to do that. There are two requirements for starting graphical applications through an SSH connection:

• An X server must be running on the client computer. The X server is the software component that creates the graphical screens.

• The remote host must be allowed to display screens on the local computer.

The easiest way to allow the remote host to display graphical screens on your computer is by adding the -Y option to the ssh command. So, use ssh -Y linda@server2 if you want to connect as linda to server2, and also be able to start graphical applications.

As you have noticed, the ssh command gives you a few options. Table 5-2 shows some of the most common options available.

As an administrator, you can also create a systemwide configuration that allows you to use X forwarding, which is starting graphical applications through an SSH session. As root, open the configuration file /etc/ssh/ssh_config and make sure it includes the following line:

ForwardX11 yes

The next time you use the ssh command, X forwarding will be available by default.

Securely Transferring Files Between Systems

If a host is running the sshd service, that service can also be used to securely transfer files between systems. To do that, you can use the scp command if you want the file to be copied, or rsync if you want to synchronize the file. Also, the sftp command is a part of the SSH solution and enables users to use an FTP command-line syntax to transfer files using sshd.

Using scp to Securely Copy Files

The scp command is similar to the cp command, which is used to copy local files, but it also includes an option that enables it to work with remote hosts. You can use scp to copy files and subdirectories to and from remote hosts, and subdirectories as well. To copy, for instance, the /etc/hosts file to the /tmp directory on server2 using your current user account, use the following command:

scp /etc/hosts server2:/tmp

If you want to connect to server2 as user root to copy the /etc/passwd file to your home directory, you use the following command:

scp root@server2:/etc/passwd ~

You can also use scp to copy an entire subdirectory structure. To do so, use the -r command, as in the following command:

scp -r server2:/etc/ /tmp

Notice that the scp command can be configured to connect to a nondefault SSH port also. It is a bit confusing, but to do this with the scp command, you need the -P option followed by the port number you want to connect to. Notice that ssh uses -p (lowercase) to specify the port it needs to connect to; the scp command uses an uppercase -P.

Using sftp to Securely Transfer Files

The sftp command provides an alternative to securely transfer files. Whereas the scp command provides an interface that is very similar to the cp command, the sftp command provides an FTP-like interface. Because even modern FTP servers are still transferring passwords and other sensitive data without using encryption, sftp should be considered as an alternative.

When working with sftp, you open an FTP client session to the remote server, where the only requirement on the remote server is that it should be running the sshd process. From the FTP client session, you use typical FTP client options, like put to upload a file or get to download a file.

Notice that when working with sftp, the local directory is important, even if after opening the FTP session you only see the remote directory on the server. When downloading a file, using the get command, the file will be stored in the current local directory, and when uploading a file using put, the file will be searched for in the local directory. Exercise 5-4 gives you a guided tour through using the sftp command and the rsync command, discussed next.

Using rsync to Synchronize Files

The rsync command uses SSH to synchronize files between a remote directory and a local directory. The advantage of synchronizing files is that only differences need to be considered. So, for example, if you synchronize a 100-MiB file in which only a few blocks have changed since the previous sync, only the changed blocks will be synchronized. This approach is also known as a delta sync.

When using the rsync command, multiple options are available. Table 5-3 provides an overview.

Configuring Key-Based Authentication for SSH

If SSH is used on the Internet, it might not be a good idea to allow password logins. To make SSH a bit more secure, it will always first try whether login using public/ private keys is possible. Only if that is not possible is a password login used. The only thing you need to do to enable key-based login is to create a key pair; everything else is organized by default already.

When using public/private key-based authentication, the user who wants to connect to a server generates a public/private key pair. The private key needs to be kept private and will never be distributed. The public key is stored in the home directory of the target user on the SSH server in the file .ssh/authorized_keys.

When authenticating using key pairs, the user generates a hash derived from the private key. This hash is sent to the server, and if on the server it proves to match the public key that is stored on the server, the user is authenticated.

Using Passphrases or Not?

When creating a public/private key pair, you are prompted for a passphrase. If you want maximal security, you should enter a passphrase. You are prompted for that passphrase each time that you are using the private key to authenticate to a remote host. That is very secure, but it is not very convenient. To create a configuration that allows for maximal convenience, you can just press the Enter key twice to confirm that you do not want to set a passphrase. This is a typical configuration that is used for authentication between servers in a trusted environment where no outside access is possible anyway.

To create a key pair, use the ssh-keygen command. The ssh-copy-id command is next used to copy the public key over to the target server. In Exercise 5-5, you create a public/private key pair to log in to the server2 host. (If no remote host is available, you can use localhost as an alternative to verify the procedure.)

After copying the public key to the remote host, it will be written to the ~/.ssh/authorized_keys file on that host. Notice that if multiple users are using keys to log in with that specific account, the authorized_keys file may contain a lot of public keys. Make sure never to overwrite it because that will wipe all keys that are used by other users as well!

Using the screen Command

You do not have to know about the screen command for the RHCSA exam, but you should know about it for your job because it enables you to open multiple terminal sessions, even if you are not in a graphical session. It also allows you to share a session with other users, as well as attach to and detach from remote terminal sessions. Before you can use screen, you need to install it. To do this, use the yum install -y screen command. Then, type screen to open a screen session. From the screen session, you can start any command you like.

The screen command is particularly useful when used from an SSH session. You can start a task that takes a long time from a screen session, detach from it, and attach to it later. The command continues running, even if you are going home and shut down your computer. The next day, you can easily attach to the screen session again to complete the task. To do this, just follow a simple procedure:

1. Open an SSH session.

2. From the SSH session, type screen to open a screen session.

3. Start whichever task you want to start and keep it running.

4. Use the Ctrl-A, D key sequence to detach from the screen session and log out from the SSH session.

5. When you are ready to reconnect, start the SSH session again. It is essential that you are using the same user account that you used before.

6. Attach to the screen session again using screen -r. You can now conveniently finish the work that you have started from the screen session before.

While working with screen, you are working in a specific application. From within this application you can issue specific commands. To use these specific screen commands, start by typing Ctrl-A, ?. This shows a list of all commands that are available. Every screen command is started with the Ctrl-A key sequence. An important command to remember is Ctrl-A, /, which will close the screen session. Make sure to remove screen sessions that you do not need anymore; otherwise, they will stay active until the next time you reboot your server!

If while trying to attach to a screen session you get a message that multiple screen sessions are currently running, you need to be more specific. To find out which screen sessions currently are running, use the screen -ls command. In Example 5-2, you can see how the screen command is used to show screen sessions that are currently in a detached state, and how the screen -r command gives a list of all currently available screen sessions, from which you can select the screen session you want to connect to by adding the number of the screen session to the screen -r command.

[sander@lab ~]$ screen
[detached from 30500.pts-0.lab]
[sander@lab ~]$ screen
[detached from 30532.pts-0.lab]
[sander@lab ~]$ screen -r
There are several suitable screens on:
          30532.pts-0.lab (Detached)
          30500.pts-0.lab (Detached)
Type "screen [-d] -r [pid.]tty.host" to resume one of them.
[sander@lab ~]$ screen -r 30500

You can also use screen to work together with other users in the same session. To do this, follow these steps:

1. Make sure that both users are using SSH to connect to the system on which you want to work together. Both users must use the same user account when using SSH to connect.

2. One user needs to start a screen session, using the screen command.

3. The second user can just connect to the screen session using screen -x.

Summary

In this chapter, you learned how to connect to Red Hat Enterprise Linux 8. You learned the difference between consoles, terminals, and shells, and you learned how to set up terminal sessions locally as well as remotely. You also learned how to use SSH to connect to a remote server and how to securely copy files between servers. At the end of this chapter you learned how you can use the screen utility to start jobs in a session you can detach from and then reattach to later.

Exam Preparation Tasks

As mentioned in the section “How to Use This Book” in the Introduction, you have several choices for exam preparation: the end-of-chapter labs; the memory tables in Appendix B; Chapter 26, “Final Preparation”; and the practice exams.

Review All Key Topics

Review the most important topics in the chapter, noted with the Key Topic icon in the outer margin of the page. Table 5-4 lists a reference of these key topics and the page number on which each is found.

Complete Tables and Lists from Memory

Print a copy of Appendix B, “Memory Tables” (found on the companion website), or at least the section for this chapter, and complete the tables and lists from memory. Appendix C, “Memory Tables Answer Key,” includes completed tables and lists to check your work.

Define Key Terms

Define the following key terms from this chapter and check your answers in the glossary:

console

terminal

tty

login shell

subshell

reboot

systemd

key-based login

public key

private key

Review Questions

The questions that follow use an open-ended format that is meant to help you test your knowledge of concepts and terminology and the breadth of your knowledge. You can find the answers to these questions in Appendix A.

1. What is the console?

2. On a server that currently has an operational graphical interface, you are at a text-based login prompt. Which key sequence do you use to switch back to your current work on the graphical interface?

3. Which command(s) show(s) all users that currently have a terminal session open to a Linux server?

4. On a server where no GUI is operational, what would you expect to be the device name that is used by the first SSH session that is opened to that server?

5. Which command would you use to get detailed information on what SSH is doing while logging in?

6. How do you initiate an SSH session with support for graphical applications?

7. What is the name of the configuration file that needs to be edited to modify SSH client settings?

8. How do you copy the /etc/hosts file to the directory /tmp on server2 using the username lisa?

9. What is the name of the file in which public keys are stored for remote users who want to log in to this machine using key-based authentication?

10. Which command enables you to generate an SSH public/private key pair?

End-of-Chapter Labs

The end-of-chapter labs help you practice what you learned throughout the chapter. The first lab is about connecting to RHEL 8 locally, and the second lab is about using SSH to log in to a remote server.

Lab 5.1

1. Log in to the local console on server1. Make sure that server1 does not show a graphical interface anymore, but just a text-based login prompt.

2. Log in from that environment and activate tty6. From tty6, switch back on the graphical interface and use the correct key sequence to go to the graphical interface.

Lab 5.2

1. Set up SSH-based authentication. From server2, use SSH to connect to server1.

2. Make sure that graphical applications are supported through the SSH session. Also set up key-based authentication so that no password has to be entered while connecting to the remote server.