A Beginner's Guide to SSH Servers (sshd)

• SSH Server Overview
• OpenBSD
• Red Hat 7.1 Linux
• EnGarde Secure Linux
• Other Linuxs

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.

OpenBSD

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.

Other Linuxs

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 option.

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.