Using Remote Connectivity for System Management

By Ross Brunson

Date: Apr 17, 2024

Return to the article

This chapter covers the following topics:

• SSH (Secure Shell)

• Executing Commands as Another User

The exam objective covered in this chapter is as follows:

• Objective 2.4: Given a scenario, configure and execute remote connectivity for system management

Used to be that you could just move your chair and work on a server system, way back in the day, but so very quickly that changed to having all the servers in the server room somewhere else, and not wanting to walk there, or even being in the location or even city or country as the servers!

Having grown up in the era of computing when using Telnet (an unsecure remote connectivity option that preceded SSH) and clear-text FTP was commonplace, I’ve witnessed the evolution of the world of remote networking from a much kinder and gentler place in which hacking was not very common to the current situation in which hacking is a persistent threat and secure terminal access to connect to remote systems safely and reliably to do work, mainly administering them, is an absolute requirement.

Today, you must have SSH installed and configured to be the most secure you can make it, as described in this chapter. You also need to know the importance of using passphrase authentication instead of password authentication to connect to a remote server or group of servers.

Another topic of great importance discussed in this chapter is the concept of privilege elevation or, as the Linux+ exam objectives state, “executing commands as another user.” This requires you to have an understanding of several different tools, both for the exam and as a responsible systems administrator.

The elevation of privilege is even more appropriate in conjunction with SSH because typically you should never allow the root user to sign in over SSH. Gaining access to root-restricted resources means you need to elevate yourself to having root access or equivalent when you get to the other system.

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz enables you to assess whether you should read this entire chapter or simply jump to the “Exam Preparation Tasks” section for review. If you are in doubt, read the entire chapter. Table 11-1 outlines the major headings in this chapter and the 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.”

Table 11-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping

1. You want to use a more secure tool than rpc to remotely copy data across the network. Which of the following tools would you use?

1. ssh-add

2. sftp

3. ssh-agent

4. scp

2. You want to disable Secure Shell logins for all users except the root user. Which of the following files would you create to make this happen?

1. /etc/nossh

2. /etc/nologin

3. /etc/disablessh

4. /etc/sshrootonly

3. The process of allowing remote-running GUI-based applications to display locally when connected to the remote system via SSH is called ________.

1. Remote Display

2. SSH GUI Mode

3. X11 Forwarding

4. Tunnel Mode

4. Which command allows you to execute commands as another user, but only if you know the other user’s password?

1. runas

2. pkexec

3. sudo

4. su

5. Which option to the su command allows you to fully take on the user’s account settings, including settings that are applied during the login process?

1. -a

2. -u

3. -l

4. -r

6. Which file is used to configure sudo access?

1. /etc/config/sudo.config

2. /etc/default/sudoers

3. /etc/sudo

4. /etc/sudoers

SSH (Secure Shell)

As mentioned at the beginning of the chapter, the Telnet protocol sends passwords and data in clear text and shouldn’t be trusted for important sessions and tasks. The Secure Shell (SSH) suite includes a protocol, a daemon, and client utilities that make your host-to-host shell sessions much more secure—about as secure as being at the physical console.

One of the features that makes SSH desirable as a remote protocol is its end-to-end encryption, which encrypts not only the username and password but also all communications.

The SSH suite replaces telnet, as well as rsh, rexec, rcp, and other unsecure utilities. You can use SSH to connect for a shell session, or you can use the scp command to remotely transfer files through the secure pipe that SSH builds between the hosts.

SSH Components

SSH includes a number of programs and files:

• ssh: Used for remote shell sessions on another host, it replaces the telnet, rsh, and rexec commands.

• scp: Used for remote copying operations, it replaces the rcp command.

• sshd: The SSH daemon.

• ssh-agent: Runs as a wrapper to the user’s session and provides authentication when requested.

• ssh-add: Loads the user’s key(s) into the agent.

The SSH package configuration files are somewhat scattered. SSH daemon and global configuration files are kept in the /etc/ssh directory, and local or user-specific configuration files are kept in the ~/.ssh directory for each user.

The global configuration files include

• /etc/ssh/sshd_config: This is the main configuration for the sshd daemon.

• /etc/ssh/ssh_host_[dr]sa_key: These files, the ssh_host_dsa_key file and the ssh_host_rsa_key file, are in the same directory and are the private parts of the host’s key structure and should be protected from public view. The permissions for these files are 600 or rw for the root user and no permissions for anyone else.

• /etc/ssh/ssh_host_[dr]sa_key.pub: These files, the ssh_host_dsa_key.pub file and the ssh_host_rsa_key.pub file, are in the same directory and are the public parts of the host’s key structure. These must be world-readable and write-only by the root user or set to 644.

• /etc/nologin: This isn’t a part of SSH. However, if it’s present, no one can log in via SSH except the root user. Non-root users see the contents of the /etc/nologin file and then are denied access to the system.

A couple of special file pairs affect how SSH works, particularly the /etc/ssh/ssh_known_hosts and ~/.ssh/known_hosts files. The global file (/etc/ssh/ssh_known_hosts) is used to check the public key of a host attempting to attach via SSH. The local file (~/.ssh/known_hosts) is the file from which the client gets the public key of the remote server. If a new connection is begun to a previously unknown host, the user sees a message saying that the host is unknown and asking whether the user wants to store the host’s key in his known hosts file. If the user answers in the affirmative, the host’s public key is added to the ~/.ssh/known_hosts file.

The /etc/ssh/ssh_known_hosts file should be world-readable and root-writable. The ~/.ssh/known_hosts file must be owned by and writable for the user.

A file of interest, the ~/.ssh/authorized_keys file, affects only a particular user’s environment. This file is used to store the public keys that can be used for logging in as this user. These keys are matched with the keys presented by an ssh or scp client upon login request.

The SSH client utilities are versatile, with a number of options available to customize the experience. You just need to know the basics for the Linux+ exam, but this section includes a few fun options.

The SSH client command is used to replace the RSH and Telnet programs specifically. Its syntax is as follows:

# ssh -l username remotehost

If you don’t specify a username with the -l option, the ssh command assumes that you want to use the name of the account with which you are locally logged in. For example, if you are logged in as the user ross and you execute the ssh command without the -l option, the command attempts to log you in as ross on the remote system.

For example, I could attach to the host mp3server as the user snuffy with this command:

# ssh -l snuffy mp3server

If I have not connected to this server before, I get a message similar to what’s shown here:

The authenticity of host 'mp3server (192.168.33.44)' can't be
established.
RSA key fingerprint is 73:4f:fa:b0:42:a4:3a:a8:64:2c:ad:26:1
d:b1: 21:e0.
Are you sure you want to continue connecting (yes/no)?

If I answer yes, the host’s public key is added to my ~/.ssh/known_hosts file and looks something like this:

192.168.3.44 ssh-rsa
AAAAB3NzaC1yc2EAAAABIwAAAIEA1gFIB9VQpFKWAZUzNM+ac/U81Tk9R8OCFfUkegVJXw
j6nqCISPyV2iJwaukcVVaVAQ+JR3EhvOvh4PhoSg4yzBSUkJ8aUBYoRSGj7PCD+vyWyi19
22HGxWbWooMBAO/Was8I7N0zQ6jxDO9qNOHcrIFeU7qbOCrKjQDM08HQjk0=

Rather than work with RCP or FTP for file transfer work, I tend to use SCP. The scp command uses the SSH protocol and encrypts the files sent from one host to another host. For example, if I wanted to transfer file1 from my root user’s home directory on my machine to the same location on a host named remotehost, I could use the following command:

# scp /root/file1 root@remotehost:/root/file1

The system would prompt me with the RSA key question (as shown in the previous ssh example) if I have not connected to this system previously from this account. I would be prompted for the password, and then the system would transfer the files. The output from a file transfer looks like this:

# root@192.168.1.73's password:
mypubkey.txt 100% |**********************| 1379 00:00

You can copy files from your host to another host, as shown previously, or copy files from a remote host to your system by reversing the source and target specifications.

You can even copy files from one remote system to another remote system. For example, the following command recursively copies the /data directory and all its contents from the remote1 host to the remote2 host after prompting you for the password for both hosts:

# scp -r root@remote1:/data root@remote2:/data

Another use of the SSH protocol is to log in to a host and use SSH to forward the output from an X client back to your display. This feature, which can be specifically invoked with the -x option, is referred to as an X11 tunnel.

SSH allows for skipping the password prompt when signing on between computers, which can be convenient if you use the ssh or scp command frequently and don’t mind the possibility that someone could sit down at your accidentally unlocked station and have her way with your network!

# find /home -iname .rhosts -exec rm -f {} \;

The following example shows the steps required to enable SSH use without a password. In this example I have two machines, fattyre and murphy, both of which are Linux workstations with the necessary SSH software loaded, as per the defaults. This demonstration assumes that fattyre and murphy are both in each other’s /etc/hosts files or resolvable via DNS.

Here’s how you can enable SSH use without passwords:

Step 1. Log in to fattyre as the root user.

Step 2. For this example, create a new user named user1:

useradd -m user1

Step 3. Set user1’s password with the passwd command to whatever you want:

passwd user1

Step 4. Switch to the user1 user account:

su - user1

Step 5. Create and set the permissions for the .ssh directory:

mkdir .ssh ; chmod 700 .ssh

Step 6. Generate an RSA key by using the ssh-keygen command:

ssh-keygen -b 1024 -t rsa

Step 7. When prompted for the location for the file, press Enter to accept the default.

Step 8. When prompted for a passphrase, enter

seatec astronomy

Step 9. Reenter the passphrase when prompted.

Step 10. Change to the .ssh directory and set the permissions on the id_rsa.pub file:

cd .ssh ; chmod 644 id_rsa.pub

Step 11. Copy the id_rsa.pub file to a new file called authorized_keys:

cp id_rsa.pub authorized_keys

Step 12. From the host murphy, ensure that you can contact the host fattyre with a ping:

ping fattyre

Step 13. Sign on to the host murphy as the root user.

Step 14. Add a user named user2:

useradd -m user2

Step 15. Set the password for user2:

passwd user2

Step 16. Enter the password twice to confirm it.

Step 17. Switch to the user2 account:

su - user2

Step 18. Make a directory and set its permissions with the following command:

mkdir .ssh ; chmod 700 .ssh

Step 19. From the host fattyre, connect to the murphy host as user2:

ssh -l user2 murphy

Step 20. When prompted about the RSA key, answer yes and then enter user2’s password.

Step 21. While logged in as user2 on the host murphy via SSH, copy the authorized_keys file from the fattyre host with the following command:

scp user1@fattyre:~/.ssh/authorized_keys ~/.ssh

The output of the scp program should look similar to this:

authorized_keys 100% |************************| 236 00:00

Step 22. Exit user2 on the host murphy and return to being user1 on fattyre.

Step 23. On fattyre as user1, invoke the ssh-agent as a wrapper to your shell:

ssh-agent $SHELL

Step 24. Add your key to the agent:

ssh-add

Step 25. When prompted for the passphrase, enter the following:

no more tears

You then see output similar to this:

Identity added: /home/ssha/.ssh/id_rsa (/home/ssha/.ssh/
id_rsa)

Step 26. Try to log in as user2 on murphy and watch what happens:

ssh -l user Murphy

You shouldn’t see any password prompt; you should see only the confirmation of where you last logged in from:

Last login: Wed May 26 13:46:55 from fattyre

Step 27. If you do see a prompt for the passphrase, enter no more tears as you did before.

This is all it takes to get two accounts and machines set up to use SSH utilities without having to enter anything but the ssh-agent command along with the passphrase. Remember that ssh-agent resides in memory and wraps a security blanket around your shell session, answering any SSH-related security requests for you. The ssh-add utility is for adding key information into the agent and doesn’t have to be run again as long as your key information remains the same.

# ssh-copy -id -i ~/zakkw/.ssh/keyfile zakkw@eternal

Tunneling

One of the greatest features of SSH is that it can tunnel—provide a conduit from inside one network, and even behind a firewall, through to another network. In many cases, using tunneling can enable you to do things that either your network administrator doesn’t want you to do or you need to do because of an overly restrictive policy, such as at a coffee shop or Internet cafe.

Let’s talk about some of the various scenarios where tunneling can come in handy.

X11 Forwarding

X is complex and hard to set up sometimes, and it might seem that tunneling X from another machine to show on yours would be hard too, but X11 forwarding is fairly straightforward due to the magical properties of ssh tunneling.

Let’s say you have a Linux system named cygnusx1 on which you want to run an application in the GUI environment, but you want that application that runs on the remote host to display on your local system.

Here’s a possible set of steps you might take:

Step 1. On a Mac, download and install XQuartz (https:/www.xquartz.org).

Step 2. Run the command ssh -X ursulak@cygnusx1.

Step 3. After a shell opens in the terminal on the remote host (cygnusx1), run the app.

Step 4. In a second or two, the remote application, running as a process on the remote host, will display on your system as if it were being run locally.

This is just an example of how forwarding X11 applications from the host they are running on to your local system would work. All sorts of things could go wrong, but that topic is beyond the scope of the Linux+ exam. The main thing is to understand the concept of X11 forwarding, which we have more than adequately covered.

Port Forwarding

Port forwarding is typically used in scenarios in which there is a need to get around some overly strict or controlling network or firewall. Keep in mind, though, that often there are very good reasons for those restrictions and rules being in place, so be responsible and don’t willingly cause issues using port forwarding.

Using SSH to forward ports takes several paths, but the main concept is the same: you are using the ssh client on one system to tunnel out to the ssh server on another system and cause services that are represented by a port on the latter system to be mapped, or to appear to be connected, to the other system.

In general, port forwarding occurs in three main ways:

Local port forwarding: This enables you to cause a remote port to be mapped to, and to appear as if it were on, your local system. Kind of like mounting an NFS share locally, mapping a port from a remote system to yours locally effectively makes your local system appear as if it is providing that service.

Remote port forwarding: Flip the scenario around and allow your local system resources to be used by a remote machine. For example, I might map a remote system’s port 8080 to my local 5500 port, and anyone connecting to that remote server on the 8080 port will get transported to my local port and service.

Dynamic port forwarding: The term dynamic port forwarding, also known as dynamic SOCKS proxying, is a method used to securely tunnel network traffic through a remote server or proxy. Sometimes you don’t want to explicitly assign ports and just want the SOCKS proxy on your system to use dynamically assigned local ports and handle all the details. Think of a situation where you need to access ports and protocols that are not allowed through a convention center’s network setup. You can use what is effectively a VPN/proxy to drill through the local restrictive network stack and connect to and communicate freely with your desired target hosts, services, and ports.

Executing Commands as Another User

There are times when you need to execute a command as a different user account. For example, if you log in to the system as a non-root user, but need to execute a command with root privileges.

This section describes methods of running commands as different user accounts, including the sudo command, the su command and the pkexec command.

The sudo Command

The problem with the su command is that to provide a user with elevated privileges, you need to provide the user with the root password, which would give that user full administrative access to the system.

Often you want to allow a regular user to execute some commands, but not all commands, as the root user. For example, if a network error occurs on a user’s workstation, you might want that user to be allowed to restart the networking service. On some systems, this can be accomplished by executing the following command:

# /etc/rc.d/init.d/network restart

To execute this command successfully, the user needs to have root privileges. This is where you either give the user the root password (which is not recommended) or you give limited root access the correct and reasonable way, via the sudo command and its partner tools.

Instead of providing the user with the root password, you can set up the sudo command to allow the user to run just the necessary command. To do this, you need to log in as the root user and then execute the visudo command.

# visudo

This command allows you to edit the /etc/sudoers file, the file that allows you to provide root access for specific commands to specific users. The visudo command automatically assumes that you want to use the vi editor to edit this file. To use a different editor, such as the nano editor, execute a command like the following:

# export EDITOR=nano

The sudoedit Command

One of the conundrums of granting a user access to edit a configuration file is that if you are using vi/vim, you are essentially giving the user the ability to run any command as root.

To prevent a user from gaining shell access with a simple set of keystrokes from vi/vim while running it as root, there exists the sudoedit command, which is really just a symbolic link to a function contained in the sudo command.

The sudoedit command lets you allow a user to use any editor, not just vi/vim. It also enables the user to edit the using sudo access, rather than having to log in to the root user account.

When a user edits a file by using the sudoedit functionality, a temporary copy of the file(s) is made, and it is owned by the user in question. Since the user is now the owner of the temporary file(s), he can successfully edit the file(s) without having root access. Upon saving the file(s), the temporary copy owned by the user is copied back to the original file location, and the original ownership is restored; the now unnecessary temporary copy is discarded.

To configure sudoedit, add the following line to the /etc/sudoers file:

%newsudo ALL = sudoedit /some/path/to/a/file

Configure the newsudo group in /etc/sudoers to have the users you want to use sudoedit, and then all they need to do is run the command:

sudoedit /path/to/that/file

The /etc/sudoers file has many options. For the Linux+ certification exam, you just need to know how to provide a user with the ability to execute commands as the root user. For example, if you want a user account with the name ross to be able to run all commands as the root user, add the following line:

ross ALL=(ALL) ALL

To limit a user to a specific command, such as the /etc/rc.d/init.d/network command, add the following line:

ross ALL=(ALL) /etc/rc.d/init.d/network

For a user to execute a command as root, she needs to use the sudo command. The syntax is as follows:

# sudo /etc/rc.d/init.d/network restart

The user is then prompted for her own password (not the root password). If the correct password is given and the access is permitted based on an entry in the /etc/sudoers file, the command is executed as the root user. If the user attempts to execute a command that she is not authorized to execute, an error message appears on the screen, and the attempt is logged.

User Privilege Escalation

Users on a Linux system come in the following types, and it is important to know all three types, which type you are logged in, and how to escalate or deescalate your privileges at will by switching from one type to another:

• Root: This is the root user, who is the super user and the most privileged user on the system. There should be only one of them, characterized by the name root and the UID (user ID) 0.

• Standard: Otherwise known as “regular” or “normal” users, these are the rank-and-file users on the system; they have no special privileges and typically have UIDs that range from 1000 and higher.

• Service: These are the accounts that have to exist to ensure that every service or daemon on the system is running as a user, since every process must have a user attached. These accounts are never signed into; they exist in the /etc/passwd file and may even have /bin/nologin as the specified shell.

The best security practice is to avoid logging in as the root user unless you need to perform specific administration commands. In most cases, you should not log in as the root user directly but rather should gain root access by executing either the su command or the sudo command.

If the wheel group is configured to have privileged access via sudo and the /etc/sudoers file, then adding a user to the wheel group gives the user those privileges. For example, in our openSUSE system, the wheel group is set up to be able to allow members of that group to execute any command, just as the root would be able to:

%wheel  ALL=(ALL) ALL

This entry is normally commented out, but it would be very easy to remove the single # comment in front of it in the default file to enable the wheel group (and its members) to have full administrative access to the system.

The su Command

To gain access to another user account with the su command, use the following syntax:

su account_name

For example, to switch to the root account, execute the following command:

# su root

This provides you with a non-login shell for the root user. Typically you want a login shell because it provides you with the full user environment (environment variables, shell customizations, and so on). This can be accomplished by using the -l option or just a - option:

# su - root
# su -l root

To gain access to a regular user account, you must provide the account name. However, if you don’t provide an account name, the su command assumes that you want to switch to the root account. As a result, the following commands are all the same:

• su - root

• su -l root

• su -

• su -l

When switching from the root account to a regular user account, no password is required. This means the root user can switch to a regular user account to test that account’s features (or troubleshoot problems for the user) without having to change that user’s password.

To switch from a regular user account to any other account, you must know the password of the account you are switching to.

PolicyKit

PolicyKit, also known as polkit, is a system service in Linux that provides a framework for controlling system-wide privileges and permissions.

PolicyKit exists to provide application-level definition and handling of unprivileged access to privileged processes. For example, you might use PolicyKit to provide a user the ability (and the rights) to perform a task by executing a command with elevated privileges. If you think that sounds like the sudo command, it’s understandable, because they both have fairly similar goals.

One difference is that PolicyKit is a little easier to use, and certainly less tedious, because you don’t have to preface almost everything you do with the sudo command.

The pkexec Command

With the previous discussion of the PolicyKit package, pkexec makes a lot more sense, as it’s the most common way to utilize the PolicyKit rules.

The pkexec command, when used to run another command, will execute that command as the targeted user. The user can be specified, but if it is not, pkexec attempts to execute the target command as the root user.

For example, to execute the lemmy.sh script as the root user, you would type

# pkexec lemmy.sh

Since a user is not specified, the default for pkexec is to attempt to run the subsequent command, script, or executable as the root user.

Summary

This chapter focused on how to remotely and securely connect with systems for the purposes of administering them, using the SSH suite of technologies and the various ssh-prefaced commands you learned about in this chapter.

You also learned about the methods for privilege elevation, or running commands or acting as another user, such as su, sudo, and pkexec.

Exam Preparation Tasks

As mentioned in the section “Goals and Methods” in the Introduction, you have a couple of choices for exam preparation: the exercises here, Chapter 23, “Final Preparation,” and the exam simulation questions in the Pearson Test Prep Software Online.

Review All Key Topics

Review the most important topics in this chapter, noted with the Key Topic icon in the left margin of the page. Table 11-2 lists these key topics and the page number on which each is found.

Table 11-2 Key Topics for Chapter 11

Define Key Terms

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

ssh

ssh-add

/etc/ssh/sshd_config

known_hosts

ssh_config

ssh-keygen

ssh-copy-id

tunneling

X11 forwarding

port forwarding

dynamic forwarding

privilege escalation

su

sudo

visudo

/etc/sudoers

sudoedit

PolicyKit

pkexec

Review Questions

The answers to these review questions are in Appendix A.

1. After configuring the PolicyKit rules for your system, what command would you use to use those rules when executing a target command that your current user doesn’t have rights to execute alone?

1. sudo

2. pkexec

3. suexec

4. execit

2. When configuring the sudo command, what is the full path and filename of its primary configuration file?

____________

3. You are able to access a remote system using just a passphrase for authentication. What must you have copied from your system to the remote system in order for this to happen?

1. Your personal public key

2. The system’s public key

3. The wheel group’s public key

4. The remote user’s private key

4. When configuring your system to allow or deny certain groups or users to sign in via SSH, what is the full path and filename of the configuration file where these settings are kept?

____________

5. If you invoke the ssh command with the -X option, what are you likely to be doing after you sign on to the remote system?

1. Just standard commands

2. Running xeyes locally and displaying remotely

3. Running X11 on the remote system and displaying locally

4. Running remote X apps that display locally

6. Which of the following commands is specifically designed to make it more secure to edit files when using sudo to elevate your privileges?

1. sudovim

2. visudo

3. sudoedit

4. nanobot

© 2024 Pearson Education, Pearson IT Certification. All rights reserved.

800 East 96th Street, Indianapolis, Indiana 46240