SSH is considered a secure protocol, and depending on your environment the default server configuration may work with a little tweaking of the daemon configuration file. Still, as we will go over in this article, there are some options you may want to configure your SSH servers for more security and control.
What is SSH?
The Secure Shell protocol is a secure alternative to the plain text rlogin, TELNET and FTP protocols. The reason SSH is considered secure is that it provides confidentiality and integrity through the use of public-key cryptography. SSH uses a client/server architecture; where an SSH client connects to an SSH server on TCP port 22 by default. It is commonly used to run remote commands or secure file transfers. There are two versions of SSH, SSH-1 and SSH-2.
This article focuses on OpenSSH version 2 on Linux
The main configuration file for the SSH server is located at /etc/ssh/sshd_config. After opening the config file in your text editor of choice go to line 28.
This is the option for permitting root login. This option should be set to no to disable directly connecting with root access. Also, line 27, can be adjusted to limit the amount of time (in seconds) the user has to log in before the connection closes.
On line 33, make sure the AuthroizedKeysFile option is not commented out (if there is a ‘#’ symbol in front of it remove it ). This is the location o.f your users authorized keys.
Make sure the PermitEmptyPasswords option is set to no so users without passwords cannot access the server remotely.
ChallengeResponseAuthentication allows the use of challenge-response passwords. If you only want to use SSH-keys for authentication then set this to no, if you plan on setting up multi-factor authentication then set this to yes.
On line 52 change the option for PasswordAuthentication to no to disable clear text password authentication.
Set line 88, UsePAM to yes to enable the use of Pluggable Authentication Modules. Most *nix based operating systems use PAM and without this option set, you may run into problems.
Now we are going to add an option that is not in our configuration file by default.
Add this rule under line 52 PasswordAuthentication; AuthenticationMethods and set it to “public-key,keyboard-interactie:pam” (without quotes). This will require users to login with both a key and password.
We can also set options on a user or group basis using the AllowUsers, DenyUsers, AllowGroups, and DenyGroups options. Simply list out users or groups separated by spaces after the options like so:
AllowUsers User1 User2
DenyGroup Group1 Group2
Finally, If you have users that only need access to SFTP you can set up an SFTP chroot for them. First create a group for the SFTP only users (ex. groupadd sftpusers. If youc an set this up for individual users as well just skip creating the group and configure the options for each user). Now in the sshd_config file and add:
Match Group sftpgroup
For individual users replace Match Group with Match User
Now, the chroot must be owned by root; you can run chown root:root /usr/chroot/username. Then add the users to the group you made earlier. Change the user’s shell to /bin/false with usermod -s /bin/false username.
We also need to remap the sftp user’s authorized_keys files. Create an authorized_keys directory in the /etc/ssh/ directory and copy the users public keys to files for each individual user (ex.mkdir -p /etc/ssh/authorized_keys/username).
Back in the sshd config file change the AuthorizedKeysFile value to /etc/ssh/authorized_keys/%u
Now when the users assigned to the sftpusers group created earlier sign in with ssh they will be dropped into their home directory and only be able to transfer files. Furthermore, if you followed the rest of this article you should have two-factor authentication and a ACL for the sshd service.
Use Cybytes and
Tip the Author!
Ready to share your knowledge and expertise?