A Beginner's Guide to SSH or Secure Shell

• Introduction
• A Personal Story on Making the Easy, Hard
• SSH Clients and Keys
• PuTTY, an SSH Windows Client
• SSH Servers - sshd

Introduction to SSH or Secure Shell

If you want to make ssh connections between Windows, Linux and or OpenBSD systems and have not yet been able to do so, this guide is for you. Since early 2000, I've been hearing that telnet and FTP are insecure and must be replaced by SSH or Secure Shell which provides encrypted connections between systems and includes telnet / rsh like, remote connections and secure file transfer plus other more advanced capabilities. OpenBSD and most Linux distributions include all the pieces for both sides of the connection, i.e. both the client and server; the OpenBSD install has the server running as do some default Linux distributions. In OpenBSD forums, I'd seen comments to the effect that its ready to go after an install but it wouldn't work for me.

Below, I'll attempt to provided the necessary steps for both sides of each of the three operating system families, Windows, Linux and OpenBSD. Regardless of the platform the software discussed runs on, nearly all of it, except the Windows clients, comes from OpenSSH which is pretty much the same group that creates OpenBSD and is developed first on OpenBSD and then moved to the other systems.

These pages are not complete. I haven't tried any Windows ssh servers yet and the related copy, FTP and agent programs are not yet covered. Tunneling of other protocols such as the X Window System is not covered either. The basics of both sides for Linux and OpenBSD as well as Windows client side connections are covered. This should meet basic needs. Often the hardest step is the first. This allows me to get something useful up now rather than delaying weeks or months.

Logically the server setup needs to come first because no ssh connections can be made until there is an sshd server running to receive them. On the other hand, you can't be sure an sshd server is running properly until someone makes a successful ssh client connection. Assuming that there are working sshd servers that users need to connect to, I'm going to cover the client side setup first. If you are an administrator responsible for setting up servers or both sides of the connection, you'll do better to review the server setup material first.

A Personal Story on Making the Easy, Hard

If you've tried, and just can't get ssh to work on a recent OpenBSD or Linux system, you may want to read this to be sure you're not doing the same thing. It also shows how obscure documentation and a seemingly unrelated system setup change can make a seemingly simple task almost impossible.

Twice in the past, spending perhaps three hours, I tried and could not get an ssh connection between two OpenBSD systems. Recently, I decided that regardless of what it took, I was going to make ssh work between my various systems. Eventually I learned that SSH is enabled by default on OpenBSD (and many recent Linuxs) provided that I did not make certain other configuration changes which had become virtually standard, before trying SSH. It takes about 30 seconds to open the lock I'd been creating, but I spent probably 20 hours finding that 30 second step.

I retrospect, the reasons for my difficulties are easily explained. Since I was familiar with telnet and FTP and not SSH and had only telnet and FTP clients on my Windows workstation, most systems set up before mid 2001 used these services. I wanted tighter security than these products normally allow and enabled TCP Wappers support by creating /etc/hosts.allow and /etc/hosts.deny files. The /etc/hosts.deny file was as conservative as possible, blocking everything not explicitly allowed in /etc/hosts.allow.

Most recent Linux and *BSD system are delivered with neither /etc/hosts.allow or /etc/hosts.deny. As long as deny is not present or does not block client access, no allow entries are needed. With sshd started by default, the host keys are created on the first boot, and with the typical default sshd_config settings, sshd will allow access to any ssh client that can reach the machine (no intervening firewalls), and supply a valid local username and password. No client keys are needed, and usernames and passwords are tunneled in the ssh connection.

The problem I'd created for myself, was that in providing extra protection to telnet and FTP, I added another layer to SSH without realizing this. This is documented on page 13 of 15 in the sshd man pages. In the "FILES" section under the heading "/etc/hosts.allow, /etc/hosts.deny". The OpenBSD man page states "If compiled with LIBwrap support, tcp-wrappers access controls may be defined here as described in hosts_access(5)." No where that I've seen does anything indicate that LIBwrap support is the default. It appears to be default in all sshd implementations I've tried. The OpenSSH FAQ does not include the term "hosts.allow". On default systems with neither file, this is not an issue. On systems like mine with a hosts.deny file that blocks everything from everywhere, allowed hosts must be explicitly authorized.

The way that I learned of the relationship between ssh and hosts.allow, which I had previously only associated with TCP Wrappers, was via EnGarde Secure Linux, www.engardelinux.com. Their modestly priced CD-ROM and printed manual had everything necessary to make an ssh connection between a Windows client and the EnGarde Linux server installed from the CD. The CD included Windows client software and the manual included step by step instructions for both systems. After this was working, searching /etc for recently changed files on the EnGarde server showed the hosts I'd enabled via the EnGarde web management interface, were entered in /etc/hosts.allow. Without EnGarde Linux, I do not believe I would ever have gotten SSH to work on OpenBSD.

Top of Page - Site Map

Copyright © 2000 - 2014 by George Shaffer. This material may be distributed only subject to the terms and conditions set forth in http://GeodSoft.com/terms.htm (or http://GeodSoft.com/cgi-bin/terms.pl). These terms are subject to change. Distribution is subject to the current terms, or at the choice of the distributor, those in an earlier, digitally signed electronic copy of http://GeodSoft.com/terms.htm (or cgi-bin/terms.pl) from the time of the distribution. Distribution of substantively modified versions of GeodSoft content is prohibited without the explicit written permission of George Shaffer. Distribution of the work or derivatives of the work, in whole or in part, for commercial purposes is prohibited unless prior written permission is obtained from George Shaffer. Distribution in accordance with these terms, for unrestricted and uncompensated public access, non profit, or internal company use is allowed.