Logging into a Local Computer, Network, logout

In order to run the shell, a user needs to log into the computer on a terminal. There are several ways to do this.
The computer may have a hardware keyboard and display for input and output directly connected to it. This is the Linux machine's physical console. The physical console supports multiple virtual consoles which act like separate terminals. Each virtual console supports an independent login session. Users can switch between them by pressing Ctrl+Alt and a function key (F1 through F6) at the same time. Most of these virtual consoles start with a text login prompt, and if the user enters their username and password correctly, they will log in and get a shell prompt.
The computer may provide a graphical desktop environment and login prompt on one of the virtual consoles. The graphical environment runs on the virtual console, so to get a shell the user must start a terminal program in the graphical environment to get a shell prompt. This would be provided in an application window of their terminal program.
If the graphical environment is available, it will run on the first virtual console in Red Hat Enterprise Linux 7. Five additional text login prompts are available on consoles two through six (or one through five if the graphical environment is turned off). With a graphical environment running, access a text login prompt on a virtual console by pressing Ctrl+Alt and pressing a function key (F2 through F6). Press Ctrl+Alt+F1 to return to the first virtual console and the graphical desktop.

Note

In Red Hat Enterprise Linux 5 and earlier, the first six virtual consoles always provided text login prompts. If the graphical environment was started, it ran on virtual console seven (accessed through Ctrl+Alt+F7).

A headless server doesn't have a keyboard and display permanently connected to it. A data center may be filled with many racks of headless servers, and not providing each with a keyboard and display saves space and expense. In order to allow administrators to log in, a headless server might have a login prompt provided by its serial console, running on a serial port which is connected to a networked console server.
The serial console would normally be used to fix the server if its own network card became misconfigured and logging in over its own network connection became impossible. But most of the time, a headless server will be accessed by other means over the network.

Logging in Over the Network

Much of the time, Linux users and administrators need to get shell access to a remote system by connecting to it over the network. In a modern computing environment, many headless servers are actually virtual machines or are running as public or private cloud instances. These systems are not physical and don't have real hardware consoles. They may not even give access to their (simulated) physical console or serial console.
In Linux, the most common way to get a shell prompt on a remote system is to use Secure Shell (SSH). Most Linux systems (including Red Hat Enterprise Linux) and macOS provide the OpenSSH command line program ssh for this purpose.
This is an example of a user with a shell prompt on the machine host using ssh to log in to the remote Linux system remotehost as the user remoteuser:

[student@host ~]$ ssh remoteuser@remotehost
remoteuser@remotehost's password: 
[remoteuser@remotehost ~]$

The connection is encrypted to secure the communication against eavesdropping or hijacking of the passwords and content being communicated.
Some systems (such as new cloud instances) do not allow users to use a password to login with ssh for tighter security. An alternative way to authenticate to a remote machine without entering a password is through public key authentication.
With this authentication method, the user has a special identity file containing a private key that's equivalent to a password, and which they keep secret. Their account on the server is configured with a matching public key which doesn't have to be secret. When logging in, the user can have ssh provide the private key and if their matching public key is installed in that account on that remote server, it will log them in without asking for a password.
In the next example, a user with a shell prompt on the machine host will log into remotehost as remoteuser using ssh with public key authentication. The -i option is used to specify the user's private key file, which is mylab.pem. The matching public key is already set up as an authorized key in the remoteuser account.

[student@host ~]$ ssh -i mylab.pem remoteuser@remotehost
[remoteuser@remotehost ~]$

In order for this to work, the private key file must be readable only by the user that owns the file. In the preceding example, where the private key is in the mylab.pem file, the command chmod 600 mylab.pem could be used to ensure this. How to set file permissions will be discussed in more detail in a later chapter.
The user might also have private keys configured which will be tried automatically, but that discussion is beyond the scope of this section. More information is available in the "OpenSSH" chapter of the System Administrator's Guide for Red Hat Enterprise Linux 7 linked in the References at the end of this section.

Note

The first time a user logs into a new machine, they may be prompted with a warning from ssh that it can't establish the authenticity of the host:

[student@host ~]$ ssh -i mylab.pem remoteuser@remotehost
The authenticity of host 'remotehost (192.0.2.42)' can't be established. 
ECDSA key fingerprint is 
47:bf:82:cd:fa:68:06:ee:d8:83:03:1a:bb:29:14:a3.
Are you sure you want to continue connecting (yes/no)? yes
[remoteuser@remotehost ~]$

Each time a user connects to a host with ssh, the host sends ssh its host key to authenticate itself and to help set up encrypted communication. The ssh command compares that against a list of saved host keys to make sure it hasn't changed. (If it has, it might indicate that someone's trying to pretend to be that host to hijack the connection).
The user will get this warning if the local machine doesn't have a host key saved for the remote host. If the user enters yes, the host key the remote host sent will be accepted and saved for future reference. Login will continue, and they shouldn't see this message again. If the user enters no, the host key will be rejected and the connection closed.
If the local machine does have a host key saved and it doesn't match the one actually sent by the remote host, the connection will automatically be closed with a warning.

Logging Out

When a user is finished using the shell and wants to quit, there are a couple of ways to end the session. The exit command terminates the current shell session. Another way to finish a session is by pressing Ctrl+D.
An example of a user logging out of an ssh session:

[remoteuser@remotehost ~]$ exit
logout
Connection to remotehost closed.
[student@host ~]$ 

References

intro(1), bash(1), console(4), pts(4), ssh(1), and ssh-keygen(1) man pages
Note: Some details of the console(4) man page, involving init(8) and inittab(5), are outdated.
More information on OpenSSH and public key authentication is available in the System Administrator's Guide for Red Hat Enterprise Linux 7