|Front | Info | Lists | Newsfeeds | Study Guide | What is BSD?|
This is the BSDA Study Guide Book written via a wiki collaboration. This is a work in progress. You may contribute to or discuss this specific page at http://bsdwiki.reedmedia.net/wiki/Configure_an_SSH_server_according_to_a_set_of_requirements.html.
Configure an SSH server according to a set of requirements
The SSH daemon's configuration file (
The following examples will present only a couple of available options along with a word of explanation, concentrating mainly on those that might be useful for limiting remote access. The OpenSSH application suite is installed as a part of base system for all BSDs. The default configuration is a good point to start.
The two most basic options for
The first one defines on which port should
Many administrators tend to change the listening port from the default port 22 (assigned by IANA for SSH communication) to a higher numbered port. It may be a good idea for keeping the logs clean of failed script kiddies' login attempts, but it can also prevent legitimate users from logging in if they're connecting from behind a restrictive firewall. There are other ways to keep a low profile without changing the default port number, as it will be discussed later in this section.
Nevertheless, one of the most important issues is to define whether
remote users will be allowed to login directly to
On BSD systems--except OpenBSD--the default option for this is:
TODO: for style guide need to cover if long dash should have spaces around it which is normal for web but not print.
The next directive that should be taken into consideration is enabling public/private key pair authentication. Setting up SSH keys is covered in section Configure an SSH server to use a key pair for authentication.
If you have absolute certainty that all of the remote users can and know how to use SSH key pairs--i.e. if all your users are competent system administrators--you can disable password-based authentication.
If you're going to leave password authentication available, make sure that at least no empty passwords will be allowed.
Note, there are some situations that empty passwords will be required,
i.e. when setting an
A final way of limiting remote access is by simply granting access only to given local accounts and/or from given remote hosts. The following directive will allow login to Mike's account from host 192.168.186.11, and John's from any host.
There can also be defined system groups, which members will be able
to login through SSH, i.e. the
This refers to deny all security model, that will allow access
only for defined users and/or groups. For the allow all model no
When combining all four directives they are processed in the following
To allow this behavior (the default is to disallow it) set this option:
Note, that the global host list can be also defined in