A Beginner's Guide to SSH Servers (sshd)
SSH Server Overview
OpenBSD and some recent Linux distributions include sshd, the SSH
server in the base install and start it automatically. To make
the simplest connection you only need to type "ssh
host_name_or_ip" to start a connection from the client side.
UNIX clients assume the current user name unless another is provided
and Windows clients include a field to provide a user name.
The standard configuration file for sshd is sshd_config. This
is located in /etc on OpenBSD systems. On Linux systems it is
likely to be in the /etc/ssh directory with other SSH related
files. sshd_config is a very simple configuration file format
with "ValueName Value" pairs with a simple space as a
separator. Comment lines begin with a "#" sign. When any changes
are made to this file, the sshd daemon must be restarted.
"# kill -HUP `cat /var/run/sshd.pid`" will work on OpenBSD and
some Linux systems. If this doesn't work on Linux, find the
appropriate initialization script and run it manually.
If the server has an /etc/hosts.deny file that deny client host
access, then OpenBSD and some distributions of Linux require
client machines to be listed in /etc/hosts.allow. Other than an
obscure reference near the end of the man pages this does not
seem to be documented. If you are having trouble making an ssh
connection (the terminal window closes in a few seconds or you
see a message similar to "Connection closed by remote host."), be
sure that computer attempting to make the client connection is
allowed in /etc/hosts.allow.
The simplest /etc/hosts.allow would contain one line "sshd: ALL".
This is strongly NOT recommend (except for testing purposes) and
should only be used if you have many incoming connections from
many users with too many diverse origins to consider controlling.
A single host can be allowed by hostname but IP addresses are
preferred as they are faster and somewhat more reliable. A
single host can be specified as 10.11.12.27/255.255.255.255 and a
class C or /24 ("slash twenty four") network as
10.11.12.0/255.255.255.0. It is not necessary to restart sshd
when hosts.allow or hosts.deny changes are made, as they are
checked each time a connection attempt is made. The safest
hosts.deny file is a simple one line "ALL: ALL" which denies all
connections not explicitly authorized in hosts.allow.
If the sshd server allows password authorization, users will be
allowed to login by providing their username and password only.
This is the default on OpenBSD. This is set in the sshd_config
when the line "PasswordAuthentication yes" is included. Password
authentication is based only on what someone, who is hopefully
the legitimate user, knows. If the user has a poor password or
has been careless with it, this is not much protection. Password
logins can be disabled by setting "PasswordAuthentication no" and
allowing RSAAuthentication which is on by default.
Some default sshd_config files, including OpenBSD allow direct
remote root logins with the line "PermitRootLogin yes". I
consider this to be a serious mistake and think this line should
always be changed to "PermitRootLogin no". This forces a remote
user to know two user passwords to login as root. First they
must know a normal user's password, then they must know root's
password as well. If the system is set up properly, the user
will also need to be a member of the group wheel, security or
root, depending on the system, to have access to su. Direct root
logins should not be allowed regardless of whether password
authentication is allowed or RSA authentication, discussed next,
is required. If root logins are not allowed and RSA
authentication is used, then the user will need to know the
normal user's RSA passphrase plus the root password.
Another default to consider changing is the ListenAddress
setting. On a machine with only one NIC, this won't matter.
On machines with two or more NICs, typically routers and
firewalls, the default is to listen on all network interfaces.
Often on machines with more than one network card there will
be good reasons for restricting ssh access to a specific card
or cards. The ListenAddress can be used to restict sshd to
listening only on the specified NICs. Assuming the Port has
already been set, all that is needed is to place the IP address
of the NIC to be allowed after the ListenAddress option.
If the machine has three or more network cards, more than one
ListenAddress option may be used. If a ListenAddress option
is provided, any NIC that has not been specified will not
accept ssh connections.
With RSA authentication allowed and password authentication
disallowed, users will be forced to login using a key pair. This
should be more secure than just a password login because now the
user has to know something, the passphrase for the key pair and
have something, the private key. Also, someone who already has
access to the remote machine, must put the public key in the
correct location. Of course the user can pick a very poor
password or do something stupid with it like leaving it on a
Post-it near the computer with the private key or save the
passphrase on the same machine as the private key.
The simplest OpenBSD configuration file is a zero
byte /etc/sshd_config. The /usr/sbin/sshd daemon won't start
unless this file is present but it does not have to have any
contents. Sshd will run with all defaults. The default
configuration file provided with OpenBSD turns off the least
secure option RhostsAuthentication and also disables X11
forwarding which is enabled by default. The sshd defaults allow
password authentication and root logins so any user including
root, may login in directly from any remote locations, unless
/etc/hosts.allow and hosts.deny are used to control what machines
are allowed access via ssh, or a firewall controls host access
outside SSH. The default configuration file does
not allow empty password logins but that's also the default.
Two recent default OpenBSD systems will allow ssh connections
with no additional configuration changes. The necessary server
keys are created automatically the first time the system boots
after the install.
Red Hat 7.1 Linux
I did a workstation install which installed the SSH client, ssh,
but not the server, sshd. This is probably included by default
in the server install but I'm not sure. If you want to use both
on the same machine, check the box that allows you to select
individual packages and be sure both are checked. If you miss
either or both, they are easy to install after the fact. Both
packages are included in /mnt/cdrom/RedHat/RPMS/ on the first
install disk. The server package is
openssh-server-2.5.2p2-5.i386.rpm. Either cd to that directory
and type "# rpm -i package_name" or type "# rpm -i" with the full
path and package name. If you are at all curious about the start
up script, after sshd is installed, cd to /etc/rc.d/init.d and
take a look at sshd. Then, to start the server, type "# ./sshd
start". To simply start the server you can type "#
/etc/rc.d/init.d/sshd start" from anywhere.
The configuration files are located in /etc/ssh. If the ssh
client is installed, ssh_config will be present here. sshd_config
will be added by rpm. "# /etc/rc.d/init.d/sshd start" will
generate the server keys in /etc/ssh. The defaults are the same
as OpenBSD except that X11 forwarding is enabled. Like OpenBSD,
RhostsAuthentication is disabled. Password authentication and
root logins are also enabled so any user including root, may
login in directly from remote locations allowed by the
combination of /etc/hosts.allow /etc/hosts.deny. For an extra
layer of security, add authorized hosts to /etc/hosts.allow. If
/etc/hosts.deny has restrictive rules, unauthorized client
computers will not be able to log in. The default
/etc/hosts.deny contains only comments. Add a new line that is
simply "ALL: ALL"; this restricts all access to only those hosts
specifically permitted in /etc/hosts.allow.
During the Red Hat 7.1 installation, I'm almost sure that I
specifically enabled ssh connections in the firewall
configuration. If I did it did not take. To allow ssh
connections on Red Hat 7.1 Linux, if you are using the default
firewall, ipchains, installed with RH 7.1, you may need to add a
new line to /etc/sysconfig/ipchains, the configuration file for
ipchains. The line should be similar to "-A input -s
allowed_net/nn -d 0/0 22 -p tcp -j accept" following the -s for
source (in this case ssh client) computer(s) put the allowed
network or hosts and slash type network mask. For example if the
local segment is 10.20.30.0 with up to 255 hosts and all
computers on that segment can ssh into the new server, use
10.20.30.0/24. If only one management workstation was allowed
access to the server that could be specified like 10.20.30.27/32.
The "0/0 22" following "-d" allows connections to any computer,
0/0, to port 22. If this is a single host with one network
interface and not a firewall with multiple network interfaces,
this is permissible and allows the host's IP address to be
reconfigured without having to reexamine the firewall rules. If
this were on an actual firewall protecting other hosts with
multiple network interfaces, then the destination would need to
be the computers that were allowed to have outside ssh
connections only and access to other computers should be blocked.
This can't be a firewall tutorial but for any host running
firewall software, the firewall must be configured to allow
appropriate connections, in addition to any configuration steps
required by SSH.
EnGarde Secure Linux
There is little point in reviewing the SSH setup with EnGarde
Linux. Everything, including a working windows client, is
provided on CD and instructions in the manual. The EnGarde setup
assumes that the web management interface is being run from a
computer which will act as a management workstation for the
EnGarde server. It's key generation function automatically puts
the public key in the user's .ssh/authorized_keys files on the
server and invokes the browser to download the private key to the
computer running the browser. They pretty much assume the person
doing the setup will be the one using ssh to access the server.
The settings go to what look like the standard location for
Linux, /etc/ssh and are somewhat more conservative than OpenBSD
or Red Hat. Password authentication is disabled. Only SSH 1,
RSAAuthentication, is supported. One could manually edit the
configuration files to provide other options but there is no
reason to assume that the web management interfaces would
recognize and not subsequently overwrite such changed settings.
Baring a thorough knowledge of the details of how EnGarde Linux,
including its web management interface works, it seems wisest to
stay within the parameters acknowledged as supported.
The locations of the files and directories /etc/ssh,
/etc/sysconfig and /etc/rc.d mentioned under Red Hat do not
appear to be included in either the recently adopted Linux
Standard Base or affiliated Filesystem Hierarchy Standard.
EnGarde uses /etc/ssh but not /etc/sysconfig or /etc/rc.d.
The following general steps are suggested. As root, check if
sshd is running with "# ps ax|grep sshd". If its running, a line
of output with a process number and /usr/sbin/sshd or possibly
just sshd should appear. Don't confuse this with the line that
is likely to show ending with "grep sshd"; that's the grep
process. If sshd is an active process and you have not manually
started it, then it's likely installed and running as a result of
system initialization scripts.
If sshd is not an active process do an "ls -l /usr/bin/sshd"; if
there is no output it's likely that sshd is not installed or
present on the system. You could try as root, "# find / -name
sshd" and if you still get no output, you can be quite sure it's
not installed. If you need to install sshd, because OpenSSH is
an OpenBSD product and you need to get the correct source version
for your Linux system, I'd recommend finding a pre built binary
package for your specific distribution of Linux, rather than
building it from source.
Use rpm, dpkg or other appropriate package command to install the
SSH server and or client as appropriate. After installing,
you'll need to locate the initialization script which should be
in some /etc/rc.d* subdirectory. Try "#find /etc -name sshd" to
locate the initialization script. You should run this to start
sshd; look it over first to see if it expects a "start" or other
parameter. Afterwards when the system reboots, sshd should start
automatically. If it does not, use "#chkconfig --list" to see
how sshd is set. It should show as on for runlevels 3, 4, and 5.
If it shows as off, then run "#chkconfig sshd on". If it does not
show in the list at all (use less or grep to be sure if there is
more than a screen of output) then run "#chkconfig --add sshd;
chkconfig sshd on".
You could check the configuration settings, typically
/etc/ssh/sshd_config, but these are probably fine for initial
testing. After verifying that sshd is working in it's more basic
modes, you may wish to review the sshd configuration and see if
changing any settings is appropriate to your environment. Once
sshd is running, an ssh client that attempts to connect to it
should tell you that the authenticity of the host cannot be
established. If instead you see a "connection closed by remote
host" message, you almost certainly have to adjust
/etc/hosts.allow. If you are having any trouble getting an ssh
connection then add the line "sshd: ALL" to /etc/hosts.allow. If
this fixes the problem or later when any other problems are
fixed, come back and change this so only specific allowed hosts
or LANs can connect. Put "ALL: ALL" in /etc/hosts.deny to
prevent any but authorized connections.
If the ssh client prompts you that the host can't be
authenticated, then the ssh client and sshd server are
communicating. If you cannot complete a login, then check the
sshd_config file to be sure that "PasswordAuthentication yes" is
set. If not, you'll never get to log in using passwords but ssh
won't tell you that for security reasons. It will let you keep
trying passwords all day long and every several attempts close
the connection. If "PasswordAuthentication no" is in the
sshd_config file change the no to yes to allow password
authentication or if "RSAAuthentication yes" is present and you
only want the more secure connection form, then generate and
locate the appropriate key pair as described in the client
section. After making any sshd_config file changes, sshd, must
be restarted. On most systems "# kill -HUP `cat
/var/run/sshd.pid`" should work. If not try the sshd
initialization script under /etc/rc* with a restart or start
Top of Page -
Copyright © 2000 - 2014 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 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