Cryptosystems: Configuring SSH
Pages: 1, 2
If you are using a hostname or FQDN instead of an IP when you use the
command, you may find that your client will hang for a moment or so while the
name is resolved. You might find a speed difference if you add an entry for the
SSH server in
/etc/hosts on the SSH client.
Let's switch gears a bit and move on to the SSH server configuration file
/etc/ssh/sshd_config. This file is similar to the SSH client file
in that all lines begin with a
# and all possible values are
listed in its manpage.
Treat the SSH daemon with more care. After all, in order to run the daemon, you need to open port 22 on that system. If that system has Internet access, anyone in the world can attempt to connect to that computer on that port. If you are using password authentication and an unauthorized user is able to guess a username and password, they will be able to login to that system with all of the rights of that user. See why root SSH logins aren't allowed and why using a public key with a passphrase protected private key is a good thing?
It is important to verify that you are using a recent version of the SSH daemon. To check the SSH server version, telnet to port 22 of the machine running the SSH daemon. If you're sitting at the server, the following command works; otherwise, telnet to the IP of the server.
telnet localhost 22 Trying ::1... Connected to localhost. Escape character is '^]'. SSH-1.99OpenSSH_3.4p1 FreeBSD-20020702 quit ^^^^^ Connection closed by foreign host.
Make sure you are running a version greater than 3.3. All software, including software designed to provide security, has the potential of being compromised, and it is important to run software that has been patched against all known exploits. This becomes doubly important for an application such as OpenSSH, which is used to allow remote users access to a system.
If you regularly run
FreeBSD system will be kept up-to-date. It is also a good idea to subscribe to
firstname.lastname@example.org, so you can be notified of new
exploits that affect your FreeBSD system as they are discovered. The FreeBSD
homepage includes directions on how
to subscribe, as well as a record of past security advisories.
You can also consider installing the most recent version of OpenSSH, which
is found in
/usr/ports/security/openssh. This article demonstrates
a FreeBSD 4.7-RELEASE system using the OpenSSH included in the base install.
There are several ways to control which hosts and users are allowed to access your SSH daemon. One is with a firewall. If you don't want anyone to access your SSH server over an Internet connection, place the SSH server behind a firewall with rules that deny access to port 22. If you do have users that will be accessing the SSH server over the Internet, you will need to add a rule that allows port 22. If your SSH clients have static IPs, you can allow just those addresses in your firewall rule.
Next, you can modify
/etc/ssh/sshd_config. First, make a
banner. While a banner itself offers no security, it does serve as a warning to
unauthorized users and may make a bit of difference if you ever need to
approach an ISP or legal authorities regarding unauthorized access. Here, I've
made a simple banner:
$ cat /etc/ssh/banner ************************************************************************ This is a private system!!! All connection attempts are logged and monitored. All unauthorized connection attempts will be investigated and handed over to the proper authorities. ************************************************************************
Then, to tell the daemon to display the banner, I'll change this line in
The banner itself will be displayed before the password or passphrase prompt. Note that banners will only be displayed to clients using SSH version 2 as they are unsupported by version 1.
If your SSH clients don't have static IPs or don't always use the same
computers to access the SSH server, it is difficult to specify source IPs in
your firewall rule. Fortunately, you can specify which users are allowed to
authenticate to the SSH server by adding the
to the SSH daemon configuration file. Here, I'll restrict access to the users
genisis and biko:
AllowUsers genisis biko
Any user that is not in that list will still receive a password prompt when
they attempt to connect to the SSH daemon. However, even if they give a correct
username and password, they will receive a permission denied message and their
connection attempt will fail. A message regarding the failed attempt will be
printed to the console of the SSH daemon, copied to
/var/log/messages and emailed to root as part of the daily
security run output. As you can see, this is a very good line to add to the SSH
daemon configuration file. To be even pickier, if your users always login from
the same system, you can do this:
AllowUsers email@example.com firstname.lastname@example.org
However, don't be that picky if your users don't always sit at the same system or if those systems don't have static IPs. For example, if genisis tries to connect from 192.168.10.1, she will receive a connection denied message.
Depending upon your requirements, you might also want to add these lines:
ClientAliveInterval 120 ClientAliveCountMax 2
The first value indicates that if the client hasn't sent any data for more than 2 minutes (120 seconds), the server will send a message to the client asking for a response. The second line indicates that if the client doesn't respond after 4 minutes (120 times 2), the server will disconnect the client.
You can also consider changing the value in this line:
to another port number. If you do so, make sure your clients are aware of
the port they must use to connect to the server so they can specify it either
on the command line or in the
ssh_config file. While this adds a
bit of security by defeating random or scripted attempts to port 22 and
preventing port 22 from showing up in a scan, a knowledgable unauthorized user
can simply telnet to your alternate port and discover that the SSH daemon is
If you don't want the world in general to know that your SSH server is running FreeBSD, you can also change this parameter:
# VersionAddendum FreeBSD-20020629
You may remember seeing that line in the output when I telnetted to port 22. If I change that to something like this:
VersionAddendum For Authorized Users Only!!!!
it will change that line in the telnet output to:
SSH-2.-OpenSSH_3.4p1 For Authorized Users Only!!!!
Note that it will still indicate the version of OpenSSH in use. This is another reason why you always want to be running a recent, fully patched version as any user who knows how to use telnet can easily find out if your SSH server is patched against known exploits.
If your SSH server has multiple IPs, all of them will listen for port 22 connection attempts by default. If you only want one of the addresses to listen, change this line:
replacing 0.0.0.0 with the desired IP address.
Remember, if you make any changes to the daemon's configuration file,
you'll need to send a "signal one" to
sshd to notify it of the
killall -1 sshd
sshd of the changes, always
use a ssh client to test your changes. For example, if I add this line:
Allowusers genisis biko
yet find that user dlavigne is still able to connect, it is time to check
that line for a typo. It is very easy to forget that parameters are case
sensitive. In this case,
AllowUsers would have worked but
Allowusers was silently ignored and failed miserably. You don't
want to find out six months later that anyone was allowed to connect when you
thought you had restricted connections to two users.
I'd like to leave you with some helpful URLs.
- An excellent Top 10 FAQs by the author of SSH The Definitive Guide
- A list of free SSH clients and servers for other operating systems
- A MacOS X SSH helper
- Directions on how to configure the SSH daemon on a Cisco router
In the next article, I'd like to continue the cryptosystems series by covering the basics of VPNs and IPsec.
Dru Lavigne is a network and systems administrator, IT instructor, author and international speaker. She has over a decade of experience administering and teaching Netware, Microsoft, Cisco, Checkpoint, SCO, Solaris, Linux, and BSD systems. A prolific author, she pens the popular FreeBSD Basics column for O'Reilly and is author of BSD Hacks and The Best of FreeBSD Basics.
Read more FreeBSD Basics columns.
Return to the BSD DevCenter.