The names for a few Linux utilities are so small that you find yourself unexpectedly launching them by entering a typo on the command line. Why bother typing lengthy words when a perfectly suitable abbreviation will suffice? One minuscule command (both in name and its pocket-sized footprint on your hard disk) is a little utility called ss.

Ss punches several levels above its flyweight class. If you're familiar with any of the popular tools used by sys admins for checking network links, I'm sure you'll be glad to hear that its functionality won't be too tricky to get your head around.

For the curious among us, the "ss" abbreviation is apparently for the words "socket statistics." Ss is bundled with the iproute2 package. If, for some highly unusual reason you don't find ss on your Debian-like system, you can always install it by running:

sudo apt-get install iproute2

A socket, is a port and an IP address. You can think of a socket as identifying a service listening on a specific port number of a specific computer. A socket pair, in this case, consists of a client IP address, a client port number, a server IP address, and a server port number. Querying information by socket therefore lets you zero in quickly on a specific service running at a specific IP address.

I would be remiss in not mentioning Unix Domain Sockets. Unix Domain Sockets, which facilitate communication between processes running on a local machine, serve a number of useful purposes, such as enabling the permissions needed to access resources between processes that would otherwise be non-privileged.

Getting Started with ss

In most scenarios, ss will run from an ordinary user account. On my system, ss resides in the /usr/sbin/ss directory. I'll start off with some basic uses for ss. The following command shows the output for IPv4 networks:

# ss -4

The abbreviated output (Listing 1) shows client and server communication. Bear in mind that a client can also be a server, and vice versa, depending on the direction of the information flow.

Replace the -4 option with -6 to output information on IPv6 connections.

As you can see in Listing 1, 192.168.0.2 is the local machine IP address, and the useful /etc/services utility has converted some port numbers into names (such as ssh, www, and smtp).

The excellent ss also offers information about TCP, UDP, local Unix Domain Sockets, and remote sockets. As I'll describe later, what makes ss exceptionally powerful is its ability to deal with the state of connections.

I often use ss to query which ports are opened by daemons installed on the computer. Use the l option to check for listening ports (Listing 2):

# ss -l

You might want to check for the listening ports during your daily sys admin routine to ensure that unexpected and potentially insecure services haven't been left enabled. Or, you might want to check for less sophisticated rootkits that might not hide their open ports effectively.

Either of the commands

lsof -i
netstat -tulpn

will help you figure out which processes (PIDs) are opening up your ports, so you can kill them off if necessary.

Simply running the ss command without any options provides a list of current "connections" (note these are actually "sockets"), as shown in Listing 3.

PIDs

If you can't get access to lsof, and you don't like netstat (I'm not a massive fan), the super-duper ss utility can also report on PIDs pertinent to your open ports. To see which processes are using sockets directly, just throw a -p into the mix:

# ss -p

One caveat is I need to log in as root to get the extended information. Listing 4 shows an example of what to expect.

Working backward from the application name, which is sshd in this case, you can see the PIDs 31195 and 31204; 31204 belongs to a non-privileged user (my login user), and 31195 appears to result from the clever privilege separation employed by sshd.

SSH is designed to minimize the chances for programming bugs causing very serious systemic issues by limiting access and restricting the service to a chrooted jail for the network-facing SSH process. To achieve this goal, SSH uses two processes. The root-owned process monitors the progress of the non-privileged process, which has a previously unused UID and GID.

Looking Deeper

You can use ss -s to retrieve screeds of statistics relating to how many sockets are open and which protocols they are using (Listing 5).

It's not the best of comparisons, but you could get a vaguely similar result using the following netstat command:

# netstat -tan | grep -v "Proto" | \
  grep -v "Active" | awk '{print $6}' | \
  uniq -c

It's definitely worth mentioning that the super ss utility has a habit of outperforming other network tools in benchmark tests. Compared with the widely-used netstat, for example, ss delivers its results very rapidly indeed. Keep in mind, however, that ss is not designed to answer every possible question but, rather, reflects the Unix philosophy that each system component should "do one thing well." Experienced users often combine ss with tools like netstat then prune the output using tools such as grep, awk, and sed.

For instance, if you would like to see which application is tying up a specific port, you could use ss with grep, as follows:

# ss | grep 58620