Configure an SSH server according to a set of requirements
Author: Cezary Morga cm@therek.net FreeBSD
Reviewer: name contact BSD flavour
Reviewer: 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
- 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)