Sort out your SSH configs

Secure Server

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

... comments powered by Disqus