What is in your toolbox? Command line edition

Command line

It has been a while since our first instalment of What is in your toolbox?. It is now 2022, we are still managing Macs and still need effective tools to perform specific tasks in our day to day workflows. Let us explore the five command line tools that help us in our roles at work.

Why? Sometimes we need more surgical precision in what we do, or we need to use one tool as part of a single step in a workflow that uses many tools together. Command line tools are like using manual transmission over automatic, giving you oodles of control (remember, with great power comes great responsibility). You can often take the result of one tool and feed it into another through scripts. The possibilities are usually only limited by your imagination; the best thing about these tools is they come with macOS – so you already have them.

The tools are:


Starting with the command to find out about all other commands, man formats and displays manual pages (or ‘manpages’) for command line tools. Just type the man command followed by the command you want to learn about.

% man command

If you have used Terminal you are probably familiar with man, but did you know the extent of its capabilities? Try this to find out more:

man man

Netcat (nc)

Netcat is used for just about anything under the sun involving TCP or UDP. We use it to check connectivity when we suspect something might be blocked on the network level. 

For example, we want to check an SMB file or print server is reachable so we will carry out a scan on port 445 with a timeout of ten seconds:

% nc -z -v -G 10 server-host-name-goes-here 445

And the result, if we can connect, is:

Connection to server-host-name-goes-here port 445 [tcp/microsoft-ds] succeeded!

If the destination host is reachable but the port is closed (so the SMB service is not running), we see:

nc: connectx to server-host-name-goes-here port 445 (tcp) failed: Connection refused

And if the destination hostname is valid but the port is blocked/stealthed (due to a network firewall/routing issue), we will get:

nc: connectx to server-host-name-goes-here port 445 (tcp) failed: Operation timed out

Finally, if the destination hostname is not valid, the command will return:

nc: getaddrinfo: nodename nor servname provided, or not known

Other common service ports we often encounter and need to check connectivity to are:

80: HTTP on web servers
443: HTTPS on web servers
389: LDAP on domain controllers/directory servers
636: Secure LDAP on domain controllers/directory servers
515: Printers using the LPD protocol (common for printers in enterprise settings with a Mac-specific queue, as LPD was historically preferred for use with macOS)
631: Printers using the IPP protocol (common for AirPrint based printers)

Find out more about nc here: 


Continuing the networking theme – do you ever need to know if your Mac is communicating properly with a specific IP address or host over the network? Tcpdump will stream a description of the contents of packets traversing the network interface on your Mac. We find it a useful tool to identify whether a troublesome application or process is actually talking with a server it is supposed to use, if the traffic is going in both directions and over which TCP ports. Handy for ascertaining whether you need to make some firewall rule exceptions etc. You will need to run this with root privileges – i.e. use sudo.

For example, if we want to see we are communicating with successfully, try:

% sudo tcpdump -n host

The -n flag will make sure we only show IP addresses and not hostnames, as well as genuine TCP port numbers instead of their friendly names.

If you initiate a successful browser connection to with the above command running, then you will see the following output:

tcpdump: data link type PKTAP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pktap, link-type PKTAP (Apple DLT_PKTAP), capture size 262144 bytes
12:20:42.638159 IP > Flags [SEW], seq 1700354665, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 639180672 ecr 0,sackOK,eol], length 0
12:20:42.757952 IP > Flags [S.E], seq 1642712968, ack 1700354666, win 65160, options [mss 1398,sackOK,TS val 3584991482 ecr 639180672,nop,wscale 7], length 0
12:20:42.758002 IP > Flags [.], ack 1, win 2057, options [nop,nop,TS val 639180791 ecr 3584991482], length 0
12:20:42.758959 IP > Flags [F.], seq 1, ack 1, win 2057, options [nop,nop,TS val 639180791 ecr 3584991482], length 0
12:20:42.875491 IP > Flags [.], ack 2, win 510, options [nop,nop,TS val 3584991602 ecr 639180791], length 0
12:20:42.875498 IP > Flags [F.], seq 1, ack 2, win 510, options [nop,nop,TS val 3584991602 ecr 639180791], length 0
12:20:42.875583 IP > Flags [.], ack 2, win 2057, options [nop,nop,TS val 639180909 ecr 3584991602], length 0

Become a tcpdump ninja – check out: 


The openssl tool is great for a couple of things that can help us – converting certificates from one format to another (say you need to upload them to a system that only likes PEM encoding but your certificate is binary DER encoded) and also viewing the certificate chain presented by a server/service you want to connect to. This one is useful when we need to check a TLS/SSL connection is direct from client to server without any SSL inspection in place (called man in the middle/MITM). Some corporate networks do that for security reasons but this may mean macOS does not trust those connections in some cases, causing them to break. By using openssl to view the certificates presented when establishing the connection, we can verify whether it is direct or filtered/inspected.

To convert a certificate from DER to PEM format (this example uses .der/.pem as extensions but sometimes certificates will have .crt or .cer depending on where they come from, irrespective of the format):

% openssl x509 -inform der -in certificatename.der -out certificatename.pem

To convert a certificate from PEM to DER encoding:

% openssl x509 -outform der -in certificatename.pem -out certificatename.der

To display the certificates presented by a server on a port bound to TLS/SSL:

% openssl s_client -showcerts -connect servername_or_ip:port

This will show you a breakdown of the certificates presented by the server/port you are connecting to, so you can check their Common Name fields to see if they come from that server directly, or an appliance doing SSL inspection on your network.

For more information about openssl, take a look at 


Now we will step away from network-related tools and focus on a Mac-specific one that is something of a Swiss Army knife… sysadminctl.

This tool lets you perform operations on user accounts (create, delete, reset passwords) as well as manipulate/work with the venerable SecureToken attribute. This is now a cornerstone when it comes to understanding FileVault and which local user accounts can enable it. It also has options for setting/querying whether a Mac is configured to update its date and time automatically, using a network time source.

An example of where we might need to use this tool is on Macs in shared lab environments that are bound to Active Directory. Users log in with Active Directory network accounts but need a local administrator account on the Macs. We can create this account during setup automatically, but as it is the first account created with a password set programmatically, it will automatically obtain a SecureToken attribute. This means if we need to change its password in future, we must use sysadminctl and know the original password. So if the account is named localadmin, we could use:

% sudo sysadminctl -resetPasswordFor localadmin -newPassword newpasswordhere -adminUser localadmin -adminPassword oldpasswordhere

Beware, if you script this it does mean having the password exposed in your script, so consider this from a security point of view before running it that way.


I know we promised you five tools – here is a bonus one. AssetCacheLocatorUtil is great if you are running a Content Caching server and want assurance your Macs on the same network can discover and use it. Just run the command by itself with no flags and it will tell you about all the Content Caches it discovers, the TCP ports they listen on and whether or not they are reachable (so you do not need to dig out tools like nc). The output is quite verbose but, if we look carefully, the lines I have extracted below are examples of the insights we can get:

% AssetCacheLocatorUtil

Found 1 content cache, rank 3, not favored, healthy, guid REDACTED, valid until 2022-01-27 15:41:00; supports personal caching: yes, and import: yes, shared caching: yes
Testing all found content caches for reachability…
This computer is able to reach all of the above content caches.