SSH and sFTP hold several hidden treasures within their config files that you might not know about, especially if you are a new sys admin. Even if you have been using them for a while, a review of some of their features might be useful.

Back in 1995, SSH (Secure Shell) was originally freeware but became increasingly proprietary with each new release. From the ground up, SSH was designed to offer different levels of encryption. Since its inception, several open source versions have surfaced, including one of the most popular implementations in 1999: OpenSSH.

In this article, I consider that SSH is focused more on creating a secure tunnel between hosts and that sFTP is a different service or protocol that sits as a subsystem of SSH, specifically for transferring files. In addition to running through a few of the config options available to SSH and sFTP when acting as servers, I will also look at one of the most network-efficient, client-side SSH protocols.

As an example, I use a stock OpenSSH server and client install on a Debian box; however, the build should suit other flavors of Linux. Although doing so is less common, you can use SSH and sFTP on Windows servers, too, and the configuration applies in most cases. I will also mention a few pointers needed for an SSH installation to get us going.

Ssshhh

Most types of servers listen for inbound connections. Upon authentication – and assuming it's set to ignore non-authenticated logins – the server then gives access to resources held by that server (or potentially other servers sitting either behind it or local to it).

After a client connects to the listening SSH daemon (server), it checks that a number of prerequisites have been satisfied. If everything is copacetic, on a Debian box the PAM (pluggable authentication module) authentication system receives a call to arms and acts as a conduit between the resources of the operating system and the server.

It's also perfectly possible to enhance SSH and PAM to use two-factor authentication employed in the financial industry. Although I haven't rolled this out, it looks very promising and works by installing a unique code on your smartphone (via a scanned QR code at install time), which you then regenerate each time you want to log in to your server.

The config file can be found at /etc/pam.d/sshd. As a non-root user, you should take a peek at the file to get an idea of what happens at the PAM level upon authentication. The sshd file is relatively readable and includes rules about locales and even Message Of The Day settings if you ever want to alter them.

Innards of the Beast

If you navigate to the /etc/ssh directory and run the ls command, you should see the daemon's config file, sshd_config (assuming, of course, that you have already installed the OpenSSH server):

apt-get install openssh-server

Additionally, you should see the client config file ssh_config, which I'll get to a little later. If you've just installed the SSH server and want to be sure that it's listening, you can use the command

lsof -i :22

which is a quick way of checking ports that are currently open. The output in my case is shown in Listing 1. As you can see, I have two instances of sshd: one faithfully listening on all iPv4 IP addresses and the other on all IPv6 IP addresses.

chris@DebianBox:~# lsof -i :22
COMMAND PID USER  FD  TYPE DEVICE SIZE/OFF NODE NAME
sshd  3328 root 3r IPv4 33323 0t0 TCP *:ssh (LISTEN)
sshd  3328 root 4u IPv6 33325 0t0 TCP *:ssh (LISTEN)

Rather than discuss each and every configuration option, I'll just describe the salient changes I would suggest making. Now would be a good time to make a copy of the original file and then read it with the less command,

cp /etc/ssh/sshd_config ~
less /etc/ssh/sshd_config

keeping the copy somewhere safe for reference.

A Stitch In Time Saves Nine

As the saying goes, it's better to make a tiny fix today than to give yourself much more work later. Thus, the very first thing I do with a new SSH server install is entirely because of experiencing repeated irritation with a quirk in the past, and that's to disable DNS lookups.

At connection time, the listening daemon will quite rightly log the IP address that's connecting and usually by default try to perform a Reverse DNS Lookup to garnish its logs with a useful hostname.

Sadly, on slow connections, any servers without adequate DNS resolvers set up and IP addresses configured without a proper reverse DNS entry present problems. Waiting for this non-essential DNS lookup to complete can be interminably painful, so the very first thing I do with a new SSH server install is disable DNS lookups. In /etc/sshd_config, you can add the following line near the bottom,

UseDNS no

then reload the service's config straight away:

# service ssh reload

At the end of my /var/log/auth.log file I now see the lines shown in Listing 2 indicating that the reload was a success and completed without errors.

Aug 19 18:10:43 localhost sshd[3328]: Received SIGHUP; restarting.
Aug 19 18:10:43 localhost sshd[3328]: Server listening on 0.0.0.0 port 22.
Aug 19 18:10:43 localhost sshd[3328]: Server listening on :: port 22.