BSD Links · New Links · Advocacy · Drivers · Events · Flavours · FAQs · Guides · Programming · Security · Software · User Groups

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 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 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 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 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 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 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 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)