Chapter 3. Remote connectivity: Safely accessing networked machines

This chapter covers

• Encryption and secure remote connections
• Linux system process management with systemd
• Extra secure and convenient password-free SSH access
• Safely copying files between remote locations with SCP
• Using remote graphic programs over SSH connections

They say that half the fun is getting there. Well, when it comes to working in a distributed computing world, not being able to get to your servers and remote resources is pretty much a show stopper. Because so much of the workload these days is being carried by the kind of virtual machine you saw in the last chapter, and because you can’t just walk up to a virtual server, push the power button, and log in, you’ll need some other access route. Welcome to the world of the Secure Shell (SSH).

3.1. The importance of encryption

In the beginning, there was Telnet for login connections over a network at any rate. The Telnet protocol was fast and reliable and, in an innocent world made up of smaller and simpler networks, perfectly serviceable. Back then, the fact that Telnet sessions sent their data packets without encryption wasn’t a big deal.

I’ve been given to understand, however, that things have changed a bit over the past few decades. This internet thing where all the cool kids play these days is a bit bigger than it used to be, and network admins no longer all know each other by their first names. Apparently, security has now become the subject of some animated discussion. Or, in other words, if you’re using Telnet to transmit private data that includes passwords and personal information in plain text over insecure networks, then you should assume it’s no longer private. In fact, anyone on the network using freely available packet-sniffing software like Wireshark can easily read everything you send and receive.

Because everyone’s regularly moving sensitive data across public networks, what’s a poor admin to do? The solution is to encrypt the data being transferred. But just what is encryption?

To protect the privacy of data even if it falls into the wrong hands, security software can use what’s known as an encryption key, which is a small file containing a random sequence of characters. As shown in figure 3.1, the key can be applied as part of an encryption algorithm to convert plain-text, readable data into what amounts to total gibberish. At least that’s how it would appear before the key is applied through a reverse application of the same algorithm. Using the key on the encrypted version of the file converts the gibberish back to its original form. As long as you and your trusted friends are the only people in possession of the key, no one else should be able to make any sense of the data, even if it’s intercepted.

Figure 3.1. A private/public key pair to encrypt and decrypt the contents of a plain-text message. This figure illustrates a symmetric encryption design.

When you log in to a remote server, you’re doing nothing more than causing data packets containing session information to be sent back and forth between two computers. The trick of secure communications is to quickly encrypt each of those packages before it’s transmitted, and then, just as quickly, decrypt them at the other end. The SSH network protocol does this so quickly and so invisibly, in fact, that someone already used to connecting through Telnet sessions won’t see any difference.

SSH was designed in the 1990s as a simple way for UNIX-like operating systems to safely encrypt the data transferred as part of remote logins. The OpenSSH implementation of the protocol is now so popular that Microsoft recently made it available natively for Windows.

3.2. Getting started with OpenSSH

In this section you’re going to check to see if OpenSSH is installed and active on your machine. Then, if necessary, you’ll install it. Because testing for a package’s active status requires understanding how modern Linux distributions manage processes, you’ll also take a detour into the world of systemd. When that’s all done, you’ll use OpenSSH to open a login session on a remote server.

If it’s not already installed, running apt install openssh-server from an Ubuntu or Debian machine will give you all the software you’ll need. But many versions of Linux distributions come with at least minimal SSH functionality right out of the box. To find what you’ve got under your hood (on Debian/Ubuntu-based machines, at least), you can use the package manager, dpkg.

The dpkg command-line tool manages and queries software packages that are part of the Advanced Package Tool (APT) system. Running dpkg with the -s flag and the name of a package returns the current installed and update status. If the package is already installed (as is true for this gedit example), the output will look something like this:

$ dpkg -s gedit                                   1
Package: gedit
Status: install ok installed                      2
Priority: optional
Section: gnome
Installed-Size: 1732
Maintainer: Ubuntu Desktop Team <ubuntu-desktop@
  lists.ubuntu.com>
Architecture: amd64
Version: 3.18.3-0ubuntu4
Replaces: gedit-common (<< 3.18.1-1ubuntu1)
Depends: python3:any (>= 3.3.2-2~), libatk1.0-0
    (>= 1.12.4)                                 3
[...]

• 1 Sample dpkg -s output for the gedit package
• 2 The package status
• 3 Two of many dependency packages

Note

In chapter 2, you saw that you can search for available packages that aren’t yet installed using apt search packagename.

As illustrated by figure 3.2, when you log in to a remote computer, your local PC is acting as a client of the remote server, so you’d use the openssh-client package. The operating system (OS) on the remote server you’re logging in to, however, is acting as a host for the shell session, so it must be running the openssh-server package.

Figure 3.2. Logging in to a remote server through an encrypted SSH connection

You can run dpkg -s openssh-client or dpkg -s openssh-server to confirm that you’ve got the right package on your machine. Because they’re built to host remote shell sessions, Linux containers will always have the full suite installed by default.

The server version also includes all the tools you’ll find in the client package. This means that someone working on a machine with the openssh-server package installed will also be able to log in via SSH to other servers. Therefore, if the client package isn’t already installed on your machine, installing the server package will cover you for anything you might need down the line.

On the other hand, security best practices teach us to limit access routes into our infrastructure to only what’s absolutely necessary. If you don’t think you’ll need to log in to your desktop or laptop, then only install openssh-client:

# apt install openssh-client

Just because a package is properly installed doesn’t mean that you’ll be able to use it right away. Sometimes the configuration files are set to inactive by default. You’ll see plenty of setup configuration examples as you work through this book, and you’ll have a look at the OpenSSH configuration files a bit later in this chapter. But there’s another common reason a Linux program might not work for you—it isn’t running. You can use systemctl status to find out whether SSH is running on your machine:

$ systemctl status ssh
? ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service;
       enabled; vendor preset: enabled)
   Active: active (running) since Mon 2017-05-15 12:37:18
       UTC; 4h 47min ago                                    1
 Main PID: 280 (sshd)                                       2
    Tasks: 8
   Memory: 10.1M
      CPU: 1.322s
   CGroup: /system.slice/ssh.service
            280 /usr/sbin/sshd -D
            894 sshd: ubuntu [priv]
            903 sshd: ubuntu@pts/4
            904 -bash
           1612 bash
           1628 sudo systemctl status ssh
           1629 systemctl status ssh
[...]

• 1 SSH is currently active.
• 2 The process ID (PID) assigned to SSH (280 in this example)

As you can see from the Active line of the output, everything is fine. If you did have to crank it up yourself though, you’d use systemctl once again, but this time with start in place of status.

Bored with your new toy? systemctl stop will neatly put it away for you:

# systemctl stop ssh

You can force a process (like SSH) to automatically load on system startup using systemctl enable ssh, or to not load on startup with systemctl disable ssh. This code snippet enables SSH:

# systemctl enable ssh

That systemctl fellow seems nice enough, but you’ve barely had the chance to meet him. Right now OpenSSH awaits us, but I’ll explain process management in greater depth at the end of this chapter.

3.3. Logging in to a remote server with SSH

Starting up remote sessions is a lot simpler than you might think. Make sure that you’ve got a second computer running somewhere with openssh-server loaded and to which you’ve network access. You could, for instance, fire up an LXC container the way you did in the previous chapter.

Now find that computer’s IP address. If you’re using an LXC container, it can give you everything you’re after via the lxc-ls --fancy command. Here’s an example showing one container called test that’s not running, and a second called base that is running, using the IP address 10.0.3.144:

# lxc-ls --fancy                                     1
[sudo] password for ubuntu:
NAME    STATE   AUTOSTART GROUPS IPV4        IPV6    2
test    STOPPED 0         -      -           -
base    RUNNING 1         -      10.0.3.144  -

• 1 Command to list LXC containers and their status details
• 2 Column headers

Alternatively, if you happen to be logged in to your server, you can get its public IP address using ip addr, which will spit out a rather nasty mess of characters listing all the local network interfaces. It looks something like this:

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue
    state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00 brd 00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
8: eth0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP>          1
         mtu 1500
    qdisc noqueue state UP group default qlen 1000
    link/ether 00:16:3e:ab:11:a5 brd
         ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.0.3.144/24 brd 10.0.3.255 scope             2
         global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:feab:11a5/64 scope link
       valid_lft forever preferred_lft forever

• 1 The public network interface (in this example, eth0)
• 2 The inet line showing the interface’s public IP address

In this case, the inet line numbered 8 in the interface is our primary interest. It shows an IP address of 10.0.3.144.

With that information in hand, to connect, you’ll need to run ssh with the name of the account on the server you’ll use to log in and the IP address. If this is the first time you’ve accessed the server from your PC, then you’ll be asked to confirm the authenticity of the information your server’s OpenSSH program sent back by typing yes. (That’s yes by the way, not just the letter y.) Finally, you’ll enter the password of the server account you specified (ubuntu, in my case), and you’re in:

$ ssh [email protected]
The authenticity of host '10.0.3.144 (10.0.3.144)' can't be established.
ECDSA key fingerprint is SHA256:BPwiWLii7e+wPhFeLxJbYDjW53SgiBvZermGT9Hqck.
Are you sure you want to continue
   connecting (yes/no)? yes                                              1
Warning: Permanently added '10.0.3.144' (ECDSA) to the list of known hosts.
[email protected]'s password:                                              2

• 1 Request for confirmation
• 2 Enter the password for your account on the remote server.

Didn’t work out the way you expected? Looks like you’re in for a terrific learning experience! The most common problem you’re likely to encounter involves network connectivity, so why not sneak a peek at chapter 14? For now, though, use ping to test whether your two computers can see and speak to each other. Assuming you’re running this from your local PC and testing its connectivity with a remote server using IP 10.0.3.144, a successful ping will look like this:

$ ping 10.0.3.144
PING 10.0.3.144 (10.0.3.144) 56(84) bytes of data.
64 bytes from 10.0.3.144: icmp_seq=1
     ttl=64 time=0.063 ms                                   1
64 bytes from 10.0.3.144: icmp_seq=2 ttl=64 time=0.068 ms
64 bytes from 10.0.3.144: icmp_seq=3 ttl=64 time=0.072 ms
64 bytes from 10.0.3.144: icmp_seq=4
     ttl=64 time=0.070 ms                                   2

• 1 Record of a successful response to a ping request
• 2 You can stop the ping requests and regain control of the command line by pressing Ctrl-c.

And failure will look like the following. To illustrate, I pinged an unused IP address:

$ ping 10.0.3.145
PING 10.0.3.145 (10.0.3.145) 56(84) bytes of data.
From 10.0.3.1 icmp_seq=1
   Destination Host Unreachable                          1
From 10.0.3.1 icmp_seq=1 Destination Host Unreachable

• 1 Record of an unsuccessful response to a ping request

3.4. Password-free SSH access

There’s something a bit depressing about passwords. They’re almost never used properly. They’re either too short and/or easy to guess, or just overused for multiple accounts. And people seem to forget them with alarming frequency. If the only thing protecting your data is a password, then the odds are that it’s not all that well protected.

That’s why the industry players with the most credibility when it comes to security—like Amazon Web Services (AWS)—will, by default, disable password authentication altogether on their cloud instances. If you’re concerned about the risk of unauthorized access to your servers, you might want to consider following their lead. Here’s what that setting looks like in the /etc/ssh/sshd_config file on an Amazon Linux instance on the EC2 service:

# EC2 uses keys for remote access
PasswordAuthentication no

The alternative to SSH password authentication is to create a special key pair and then copy the public half of the pair to the remote host, which is the computer where you eventually want to log in. With encryption keys available at both ends of the connection, OpenSSH running on the host will now have a way to know who you are without having to demand a password. That’s not to say passwords have no positive role to play in infrastructure security. In fact, you’ll soon see how. Ideally, you should create what is called a passphrase and use it to authenticate yourself locally before using your key pair.

Note

A passphrase, like a password, is a secret text string that you’ve chosen. But a passphrase will often also include spaces and consist of a sequence of real words. A password like 3Kjsi&*cn@PO is pretty good, but a passphrase like “fully tired cares mound” might be even better because of its length and the fact that it’s relatively easy to remember.

3.4.1. Generating a new key pair

There’s definitely more than one way to skin this cat. But since all good system administrators are, by training, lazy, I’ll go with the approach that requires the fewest keystrokes. An unintended but happy consequence of this choice is that I’ll get to introduce you to a much more sophisticated use of the pipe character (|).

You’ll begin by creating a new public/private key pair on the client computer using the ssh-keygen program. You’ll be asked for a key pair name, but, unless you’ve already got a pair called id_rsa, I’d just press Enter and stick with the default. As you saw previously, it’s usually better to create a passphrase when prompted, especially if you share your computer with others. Remember, if you do opt to add a passphrase, you’ll be prompted to enter it each time you use the key. Here’s how all that will go:

ubuntu@base:~$ ssh-keygen                                       1
Generating public/private rsa key pair.
Enter file in which to save the key (/home/ubuntu/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in
    /home/ubuntu/.ssh/id_rsa.
Your public key has been saved in
    /home/ubuntu/.ssh/id_rsa.pub.                               2
The key fingerprint is:                                         3
SHA256:1wQzEnybUSOFpYEvmbxVPZjy1uGAV6Tnn5m1w0qD5T8 ubuntu@base
The key's randomart image is:                                   4
+---[RSA 2048]----+
|       .oo**=*o  |
|        o.*B*o+  |
|       . =.Oo+.o |
|        = =oooo  |
|        S+..... .|
|        ..  + ..*|
|           . + B.|
|            . +E.|
|             . ..|
+----[SHA256]-----+

• 1 Displays the name of my local client, base
• 2 The location and name of your new key pair
• 3 Helps to prevent man-in-the-middle attacks
• 4 The key’s randomart, a visual cue, also helps to prevent man-in-the-middle attacks.

Well, now you’re the proud owner of a shiny new RSA encryption-based key pair. Go ahead and use ls -l to display a long list of the contents of your .ssh/ directory. Notice how there are two files with the name id_rsa, but only one of them has the .pub filename extension. That file is the public half of the pair, and it’s the file you’ll eventually copy to the remote machine that will be your session host:

ubuntu@base:~$ ls -l .ssh
total 12
-rw------- 1 ubuntu ubuntu 1675 Jun  5 22:47 id_rsa
-rw-r--r-- 1 ubuntu ubuntu  393 Jun  5 22:47 id_rsa.pub

3.4.2. Copying the public key over a network

Passwordless SSH access doesn’t work until you copy the public key over to the host. As you can see in figure 3.3, the key pair is generally created on a client computer. That’s because the private key should be just that: private. As much as possible, you want to avoid moving it around unnecessarily and exposing it to unfriendly eyes.

Figure 3.3. The public key of a key pair must be moved to the host PC, while the private key remains on the client.

Once created, you can move the public key to the file .ssh/authorized_keys on the host computer. That way the OpenSSH software running on the host will be able to verify the authenticity of a cryptographic message created by the private key on the client. Once the message is verified, the SSH session will be allowed to begin.

The first thing you’ll need to do is figure out which user account on the host you’ll be logging in to. In my case, it’ll be the account called ubuntu. The key needs to be copied to a directory called .ssh/, which is beneath /home/ubuntu/. In case it’s not there already, you should create it now using mkdir.

First, though, I’ll introduce you to a cool shortcut: to run a single command, you don’t need to actually open a full SSH session on a remote host. Instead, you can append your command to the regular ssh syntax like this:

ubuntu@base:~$ ssh [email protected] mkdir -p .ssh
[email protected]'s password:

You’ll still need to provide the password to the remote host. But once that’s done, you’ll have a .ssh/ directory beneath /home/ubuntu/ on the host.

To make it easier for you to read, I split this next command into three lines using the backslash character (), which tells Bash to read the next line as part of the current line. Make sure there are no characters (including a space) after the backslash. That’s guaranteed to cause you grief:

ubuntu@base:~$ cat .ssh/id_rsa.pub         1
 | ssh [email protected]                   2
"cat >> .ssh/authorized_keys"               3
[email protected]'s password:

• 1 The cat command reads the contents of the id_rsa.pub file.
• 2 The text is piped to the ssh command.
• 3 The text is appended to a file called authorized_keys.

That single, multi line command will use cat to read all the text in the id_rsa.pub file and store it in memory. It will then pipe that text via an SSH logon on the remote host computer. Finally, it reads the text once again, this time on the host computer, and appends it to a file called authorized_keys. If the file doesn’t yet exist, >> (the append tool) creates it. If a file with that name already exists, the text will be added to any content in the file.

That’s it. You’re ready to roll. This time, when you run the same old ssh command, there’s no need to enter a password:

ubuntu@base:~$ ssh [email protected]                               1
Welcome to Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-78-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage
Last login: Tue May 16 15:14:37 2017 from 10.0.3.1
ubuntu@tester:~$                                                   2

• 1 The login proceeds without a password request.
• 2 The new command prompt indicates that you’re on a different computer.

3.4.3. Working with multiple encryption keys

There will be cases (like having to log in to a virtual machine instance running on Amazon’s EC2 service) where you’ll need to specify which key pair to use for a given session. This will definitely happen once you start building a collection of keys used for different hosts. To tell OpenSSH which key you’re after, you add the -i flag, followed by the full name and location of the private key file:

ssh -i .ssh/mykey.pem [email protected]

Notice the .pem file extension in that example? That means the key is saved with a format that’s commonly used to access all kinds of VMs, including Amazon EC2 instances.

3.5. Safely copying files with SCP

I’m sure you remember how the cp command copies files and directories from place to place within a file system. Well, in theory at least, there’s no reason why that couldn’t work just as well for copying files across a network. Except that it would be stark raving bonkers—the file contents would be exposed to anyone else who happened to be hanging around the network that day, or anyone who happened to be browsing through network log data some time later.

Forget that idea, unless you add an s for secure in front of that cp command. The SCP program copies files of any sort hither and yon using the SSH protocol for file transfer, relying on all the same keys, passwords, and passphrases. Assuming that you knew there was already a .ssh/ directory on the remote host you worked with earlier, here’s how you could have transferred the public key (id_rsa.pub) to the remote host, renaming it authorized_keys:

ubuntu@base:~$ scp .ssh/id_rsa.pub 
  [email protected]:/home/ubuntu/.ssh/authorized_keys

Warning

If there already was an authorized_keys file in that directory, this operation would overwrite it, destroying any existing contents. And, you can only copy or save files if the user accounts you’re using have appropriate permissions. Therefore, don’t try saving a file to, say, the /etc/ directory on a remote machine if your user doesn’t have root privileges. Before you ask, logging in to an SSH session as the root user is generally a big security no-no.

You can, by the way, copy remote files to your local machine. This example copies a file from an AWS EC2 instance (represented by a fictitious IP address) to the specified local directory:

$ scp -i mykey.pem [email protected]:/home/mylogin/backup-file.tar.gz 
  ./backups/january/                                                       1

• 1 Saves the file to a directory location relative to the current work directory

The commands you’ve used up to this point have illustrated some important tools. But I should mention that there’s a third (and official) way to safely copy your key over to a remote host—the purpose-built program called ssh-copy-id:

$ ssh-copy-id -i .ssh/id_rsa.pub [email protected]         1

• 1 Automatically copies the public key to the appropriate location on the remote host

The nice thing about SSH sessions is that, unburdened by layers of GUI stuff, they’re fast and efficient. But that can be a problem if the program you need to run on the remote host is of the graphic persuasion. The next section solves that problem for you.

3.6. Using remote graphic programs over SSH connections

Suppose you’re trying to support a user in a remote location who’s reporting trouble with a piece of desktop software like LibreOffice. If you feel that being able to launch and run the program could help diagnose and solve the problem, then it can be done using a graphic session (with the Linux X window manager) over SSH.

Having said that, don’t expect miracles. Running ssh with the -X flag, using what’s called X11 forwarding, will allow you to load a host machine-based program in the desktop of your client. Depending on a number of factors, including the quality of your network connection, your results may not meet your expectations. This is especially true of resource-heavy programs like LibreOffice. Nevertheless, it’s always worth a try. Suffering through a little low bandwidth might still beat a two-hour drive to a client’s office.

One more thing: don’t try this on a server. In most cases, the OS version installed on a server or VM (like an LXC or a Docker container) comes with little or no graphic functionality. If you absolutely must, you can install the desktop packages to upgrade it. On an Ubuntu machine, it would look like this:

# apt update
# apt install ubuntu-desktop

With all of the disclaimers out of the way, I’d say it’s time to see how this actually works. First off, open the sshd_config file on the host machine (the one whose program you want to run). You’ll need to make sure that the X11Forwarding line has the value yes (although, for security considerations, it’s probably not a good idea to leave it that way any longer than necessary):

# nano /etc/ssh/sshd_config
    X11Forwarding yes         1

• 1 Edit the line to look exactly like this.

There’s a similar line in the ssh_config file on the client machine that will also need to be set correctly:

# nano /etc/ssh/ssh_config
    ForwardX11 yes            1

• 1 Edit the line to look exactly like this.

Because you’ve edited the configuration files, you’ll need to restart SSH on both machines to make sure that your changes are live:

# systemctl restart ssh

And you’re ready to go. To start a session that’s graphic-enabled, add the -X flag to your ssh command:

$ ssh -X [email protected]

You’ll see the regular command prompt, but you’ll now be able to run a command that will launch a graphic program. Try something small. This should work on an Ubuntu system:

$ gnome-mines

Amazing! You’re successfully running a remote program from a window on your local desktop.

OpenSSH brings a great deal more value to the table than the core features you’ve already seen. Once you’ve got a working SSH connection, there are all kinds of tricks you can pull off. Try mounting a local file system or directory on a remote machine, allowing remote users to seamlessly access your files. Or, through the magic of SSH tunneling, use port forwarding to permit the secure, private use of remote HTTP services.

3.7. Linux process management

As promised, now I’m going to revisit Linux process management so you can properly understand how programs like OpenSSH are handled. Knowing how these things work can make general administration and troubleshooting much more effective in the long run. But if you don’t feel inspired to dive into such an involved topic right now, you can safely skip the rest of this chapter. You should have no problem following along with the rest of the book.

Just what is systemctl, and what’s it actually doing? To properly answer those questions, you’ll have to think for a bit about how Linux manages system processes in general. And because it’s always nice to meet new friends, you’ll also learn about some process-tracking tools to make understanding the way things work easier.

Software, as I’m sure you already know, is programming code containing instructions to control computer hardware on behalf of human users. A process is an instance of a running software program. An operating system is a tool for organizing and managing those instances/processes to effectively use a computer’s hardware resources.

Organizing and managing processes for a complex multiprocess, multiuser operating environment is no simple task. To make it work, you’ll need some kind of traffic cop to tightly control the many moving parts (figure 3.4). Let me introduce you to systemctl.

Figure 3.4. The availability and responsiveness of many system services are managed by systemd’s systemctl process manager.

3.7.1. Viewing processes with the ps command

Let’s pull out an electron microscope and see if we can’t spot a process in its natural habitat. Type the following command into a terminal. It will do nothing (sleep) in the background (&) for 10 seconds and then stop. While it’s running, though, type ps:

$ for i in {1..10}; do sleep 1; done &
[1] 19829                                1
$ ps
  PID TTY          TIME CMD
19522 pts/17   00:00:00 bash
19829 pts/17   00:00:00 bash
19832 pts/17   00:00:00 sleep            2
19833 pts/17   00:00:00 ps               3

• 1 The PID of the command running in the background
• 2 The sleep process launched by the original comman
• 3 The ps command to list running processes

What you’ll see is a record of the two running processes spawned by that command, along with their PIDs: 19829 and 19832, in my case. If you run ps once again after waiting 10 seconds, you’ll see those two processes are no longer running. You should also see a report of the successful completion of the sleep command:

$ ps
  PID TTY          TIME CMD
19522 pts/17   00:00:00 bash
20549 pts/17   00:00:00 ps
[1]+  Done                    for i in {1..10};
do
    sleep 1;
done

Normally, if you were to type just ps and run it, you’d probably get only two results. The first, a process called bash that represents the Bash command interpreter being used by your current shell session, and the most recent command (which, of course, was ps). But by looking at the PID assigned to bash (7447, in the following example), you know there are lots and lots of other processes already hard at work somewhere on your system. These will have been spawned by parent shells going all the way back to the init process itself:

$ ps
 PID TTY          TIME CMD
7447 pts/3    00:00:00 bash
8041 pts/3    00:00:00 ps

On an Ubuntu machine, the first process to wake up and get everything else going when a Linux computer boots is called init. As you’ll soon discover, that name can be misleading, which is why the first process has a different name on CentOS. You can see for yourself that init is first by running the following ps command exactly the way it’s printed here. I’ll explain the details in just a minute:

$ ps -ef | grep init
root         1     0  0 12:36 ?        00:00:00 /sbin/init                1
ubuntu    1406   904  0 16:26 pts/4    00:00:00 grep --color=auto init

• 1 The file responsible for process 1

The rightmost column of the output (/sbin/init on the first line) represents the location and name of the file behind the process itself. In this case, it’s a file called init that lives in the /sbin/ directory. The leftmost column on this first line contains the word root and tells you that the owner of this process is the root user. The only other piece of information that is of interest right now is the number 1, which is the PID of the init process. The only way you’re going to get PID 1 is by getting there before anyone else.

Before moving on, it’s worth spending a bit more time with ps. As you’ve seen, ps displays information about active processes. It’s often important to have access to process-related information so you can properly plan and troubleshoot system behavior. You can expect to use ps early and often.

Adding the -e argument to ps as you did previously returns not only the processes running in your current child shell, but all the processes from all parent shells right back up to init.

Note

A parent shell is a shell environment from within which new (child) shells can subsequently be launched and through which programs run. You can think of your GUI desktop session as a shell, and the terminal you open to get a command line as its child. The top-level shell (the grandparent?) is the one that’s run first when Linux boots.

If you want to visualize parent and child shells/processes, you can use the pstree command (adding the -p argument to display the PIDs for each process). Note how the first process (assigned PID 1) is systemd. On older versions of Linux (Ubuntu 14.04 and earlier, for instance), this would have been called init instead:

$ pstree -p                                  1
systemd(1)agetty(264)                    2
            agetty(266)
            agetty(267)
            agetty(268)
            agetty(269)
            apache2(320)apache2(351)
                            apache2(352)
                            apache2(353)
                            apache2(354)
                            apache2(355)
            cron(118)
            dbus-daemon(109)
            dhclient(204)
            dockerd(236)docker-containe(390){docker-containe}(392)
                                                    {docker-containe}(404)
                            {dockerd}(306)
                            {dockerd}(409)
            mysqld(280){mysqld}(325)
                           {mysqld}(326)
                           {mysqld}(399)
            nmbd(294)
            rsyslogd(116){in:imklog}(166)
                             {in:imuxsock}(165)
                             {rs:main Q:Reg}(167)
            smbd(174)smbd(203)
                         smbd(313)
            sshd(239)sshd(840)sshd(849)bash(850)pstree(15328)
            systemd-journal(42)
            systemd-logind(108)

• 1 CentOS users might need to install the psmisc package to run pstree.
• 2 systemd, the top-level parent process

Go ahead and try all these commands on your machine. Even on a quiet system, you’ll probably see dozens of processes; a busy desktop PC or server can easily have hundreds or even thousands.

3.7.2. Working with systemd

There’s something interesting about that /sbin/init file you just saw: file is a venerable UNIX program that gives you insider information about a file. If you run file with /sbin/init as its argument, you’ll see that the init file is not actually a program, but a symbolic link to a program called systemd. We’ll talk more about symbolic links in chapter 12, but here’s where you get to meet systemd:

$ file /sbin/init
/sbin/init: symbolic link to /lib/systemd/systemd

It took years of fragmentation and some vigorous political infighting, but nearly all Linux distributions now use the same process manager: systemd. It’s a drop-in replacement for a process called init, which has long been the very first process started during the boot process of all UNIX-based operating systems. By drop-in replacement, I mean that, even if the way it gets things done can be quite different, to the casual observer, systemd functions like init always did. That’s why the /sbin/init file is now nothing more than a link to the systemd program.

This is all a bit theoretical as you’ll probably never actually invoke the systemd program itself by name, either directly or through its /sbin/init frontend. This is because, as you’ve already seen, the key administration tasks are handled by systemctl on behalf of systemd.

Technically, systemd’s primary job is to control the ways individual processes are born, live their lives, and then die. The systemctl command you used previously is the tool of choice for those tasks. But, somewhat controversially, the systemd developers expanded the functionality far beyond the traditional role of process management to take control over various system services. Included under the new systemd umbrella are tools like a logging manager (journald), network manager (networkd), and device manager (you guessed it: udevd). Curious? The d stands for daemon, a background system process.

You’ll cross paths with at least some of those systemd tools as you work through the book. Our next stop will be learning how to manage and, most importantly, back up file systems and archives.

Summary

• Encrypted connections are a critical part of all networked communications, and SSH is pretty much the industry standard.
• You can enable password-free SSH access by sharing the public key of a key pair.
• The OpenSSH package also allows for secure file copying and remote graphic sessions.
• On most modern Linux distributions, processes are managed by systemd through the systemctl tool.
• You can pipe data between commands using the | (pipe) character and filter streaming data with grep.

Key terms

• A password is a string of regular characters, while a passphrase can include spaces and punctuation.
• RSA is a popular encryption algorithm.
• X11 forwarding allows graphic programs to be run over a remote connection.
• A Linux process is all the ongoing activity that’s associated with a single running program.
• A shell is a terminal environment that provides a command-line interpreter (like Bash) to allow a user to execute commands. When you’re working from a Linux desktop PC or laptop, you’ll generally access a shell by opening a terminal program (like GNOME Terminal).
• A parent shell is an initial environment, from within which new child shells can subsequently be launched and through which programs run. A shell is, for all intents and purposes, also a process.

Security best practices

• Always encrypt remote login sessions running over a public network.
• Avoid relying on passwords alone; like people, they’re fallible.
• Key-based, passwordless SSH sessions are preferable to simple password logins.
• Never transfer files across public networks in plain text.

Command-line review

• dpkg -s openssh-client checks the status of an APT-based software package.
• systemctl status ssh checks the status of a system process (systemd).
• systemctl start ssh starts a service.
• ip addr lists all the network interfaces on a computer.
• ssh-keygen generates a new pair of SSH keys.
• $ cat .ssh/id_rsa.pub | ssh [email protected] "cat >> .ssh/authorized_keys" copies a local key and pastes it on a remote machine.
• ssh-copy-id -i .ssh/id_rsa.pub [email protected] safely copies encryption keys (recommended and standard).
• ssh -i .ssh/mykey.pem [email protected] specifies a particular key pair.
• scp myfile [email protected]:/home/ubuntu/myfile safely copies a local file to a remote computer.
• ssh -X [email protected] allows you to log in to a remote host for a graphics-enabled session.
• ps -ef | grep init displays all currently running system processes and filters results using the string init.
• pstree -p displays all currently running system processes in a visual tree format.

Test yourself

1

The purpose of an encryption key is to:

1. Establish a secure network connection
2. Encrypt and decrypt data packets
3. Obscure sensitive data in transit
4. Ensure the reliability of data transmissions

2

You can check the status of a service using which of the following commands?

1. dpkg -s <servicename>
2. systemd status <servicename>
3. systemctl status <servicename>
4. systemctl <servicename> status

3

Which of these packages must be installed before a host server can accept remote SSH logins?

1. openssh-server
2. ssh-server
3. openssh-client
4. ssh-client

4

On a Linux distribution using systemd, the job of init is performed by which of these programs?

1. /lib/systemd/systemd
2. /bin/systemd
3. /sbin/init
4. /bin/init

5

Which of the following services is not a systemd service?

1. networkd
2. journald
3. processd
4. udevd

6

For passwordless SSH connections, where must the keys be placed?

1. Public and private keys on the host, private key on the client
2. Public and private keys on the host, public key on the client
3. Private key on the host, public key on the client
4. Public key on the host, private key on the client

7

What is the purpose of a passphrase in SSH sessions?

1. To authenticate your identity to the remote OpenSSH program
2. To authenticate your identity to the local OpenSSH program
3. To identify which key pair you want to use
4. To authenticate the status of the key pair

8

Which of the following will copy a remote file to the current directory on your local machine (assuming both the remote directory and file exist)?

1. scp [email protected]:/home/mylogin/filename .
2. scp [email protected]/home/mylogin/filename .
3. scp [email protected]:/home/mylogin/filename
4. 
   

   scp [email protected]:/home/mylogin/filename
    ./home/myname/Documents

Answer key

1.

b

2.

c

3.

a

4.

a

5.

c

6.

d

7.

b

8.

a