## Configure an SSH server according to a set of requirements ##

[Author](authors.html): Cezary Morga cm@therek.net FreeBSD

[Reviewer](technical_reviewers.html): _name_ _[[contact]]_ _[[BSD_flavour]]_

[Reviewer](technical_reviewers.html): _name_ _[[contact]]_ _[[BSD_flavour]]_

----

### Concept ###

* Be aware that the `sshd(8)` built into BSD systems can be configured to limit who can access a system via SSH.


### Introduction ###

The SSH (((SSH))) daemon's configuration file (`/etc/ssh/sshd_config`) allows--among other things--limiting remote users' access to the system. For any changes made to the file to take effect, the `sshd` daemon must be either restarted or sent the SIGHUP (((HUP signal))) signal. Sending signals to processes is described in section [[View_and_send_signals_to_active_processes]].

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 (((OPenSSH))) application
suite is installed as a part of base system for all BSDs. The default configuration is a good point to start.

### Examples ###

The two most basic options for `sshd` configuration are:

""Port 22
""Protocol 2

The first one defines on which port (((port, network))) should `sshd(8)` listen on, while the
latter specifies which SSH protocol version should be used. It is
advisable to use only SSH version 2.

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 `root` account. This 
should definitely be forbidden. You or any other administrator
can login to your own accounts and then `su(1)` to `root` whenever
necessary.

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.

""PermitRootLogin no

The next directive that should be taken into consideration is enabling
public/private key pair (((key pair))) authentication. Setting up SSH keys is covered
in section [[Configure_an_SSH_server_to_use_a_key_pair_for_authentication]].

""PubkeyAuthentication yes

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.

""PasswordAuthentication yes
""PermitEmptyPasswords no

Note, there are some situations that empty passwords will be required,
i.e. when setting an `anoncvs` repository.

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.

""AllowUsers mike@192.168.186.11 john

There can also be defined system groups, which members will be able
to login through SSH, i.e. the `staff` group.

""AllowGroups staff

This refers to _deny all_ security (((security))) model, that will allow access
only for defined users and/or groups. For the _allow all_ model no
`AllowUsers` or `AllowGroups` need to be specified. Furthermore,
we can define which users or user groups are to be denied access using
the `DenyUsers` or `DenyGroups` directives respectively.

When combining all four directives they are processed in the following
order: `DenyUsers`, `AllowUsers`, `DenyGroups`, and `AllowGroups`.

The `AllowUsers` and `DenyUsers` options can be used for globally
defining from which hosts users can login. Users can also define this for themselves
through the `.rhosts` file. Still, this directive refers only to logins authenticated correctly through 
the SSH keys system.

To allow this behavior (the default is to disallow it) set this option:

""HostbasedAuthentication yes

Note, that the global host list can be also defined in `hosts.equiv`.

### Practice Exercises ###

1. Check the `sshd` configuration file on your system, add access and connection
(protocol, port) limits. Verify the results connecting from different machine.

### More information ###

`sshd\_config(5)`