A Beginner's Guide to SSH or Secure Shell
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
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
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,
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 -
Copyright © 2000 - 2012 by George Shaffer. This material may be
distributed only subject to the terms and conditions set forth in
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 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.