How Secure can Secure Shell (SSH) Be? (BASIC CONFIGURATION of OpenSSH)

Secure Shell is one of the protocols that IT specialists use to ensure a secure and reliable connection between remote computer systems. This short guide explains a few things to make your SSH connection more secure. For FreeBSD and OpenBSD, SSH starts automatically if you did not remove the check from the sshd box during installation.
OpenBSD (immediately):
# /etc/rc.d/sshd start
OpenBSD (permanently):
# vi /etc/rc.conf.local
Create the line used when starting sshd_flags and leave it empty like this sshd _ flags=”” or you can specify your own path to the configuration file, so the line should look like sshd _ flags=”-f /MY _ PATH/my _ config _ filename”.  Changes will take effect after restarting the system, or you can use the command line to do it immediately.
# /etc/rc.d/sshd start
or restart when sshd is running.
# /etc/rc.d/sshd restart
FreeBSD (immediately):
# /etc/rc.d/sshd start
or
# service sshd start
FreeBSD (permanently):
# vi /etc/rc.conf

Create the line started at sshd_enable=”YES”.
You can specify your own path to the configuration file. Edit the following file.
# vi /etc/rc.d/sshd
Find the line started at command=”/usr/sbin/${name}” and change it as following.
command=”/usr/sbin/${name} -f /MY_PATH/my_config_filename “
Changes will take effect after restarting the system, or you can use the command line to do it immediately.
# vi /etc/rc.d/sshd restart
Note
Do not specify your own configuration file when you run for the first time.
sshd configuration file explanation
The configuration file in this example was tested and operated correctly for FreeBSD 9.1 and OpenBSD 5.3.
Warning
AuthenticationMethods publickey, password publickey, keyboard-interactive does not work at FreeBSD (maybe in the next releases) and the value of the option UsePrivilegeSeparation sandbox works in OpenBSD. As for the rest UsePrivilegeSeparation, yes, it works.
Every time you change your configuration, you can check its validity by using the test mode, or extended test mode, as shown below respectively:
# sshd –t
# sshd -T
If you are not familiar with sshd, please use the following command to restart the process, or read the text from beginning. After installation of your *BSD system, sshd should be installed and run at start up by default.
# /etc/rc.d/sshd restart
You can experiment with the SSH options and values (in sshd _ config) and you will not lose your current SSH connection(s) because the new sshd process serves only new connections. But if you close the current connection(s) and then you try to reach the server the new sshd process with the new configuration will be used.
Let’s look at the sshd (ssh daemon) configuration file, bit by bit, from beginning to end. The file is always located at /etc/ssh/sshd_config, but it can be changed (moved or a new one created) if you wish (see PART 1).
Note
The commented lines are not listed if they are not necessary, so not all of your options have been displayed which you will see in your file.
sshd_config 1st part listing:
Port 4444
AddressFamily inet
ListenAddress 192.168.0.1
#ListenAddress ::
Port and then decimal number of the port, where sshd listens and waits for new connections (IP address + port number = socket). Standard port is 22, so It is is recommended to change it for your own security, and select a range <1024-65535>. It reduces up to 90% of the sniffers that are searching for port 22 and then trying to log in using a dictionary attack, or brute force. Thus, it decreases the load on your server and reduces probability of access to your system.
AddressFamily and then inet for IPv4, inet6 for IPv6 and any for both. If you do not use IP version 6, It is good practice to disable it, so only use inet. Please remember: if you do not need something, just do not use it and disable it.
ListenAddress and then an IPv4 decimal four octets IP address, such as 192.168.0.1, where sshd listens and waits for new connections. Please do not use a locahost IP address (127.0.0.1), because you will never connect to your server from the outside (better security, but weaker functionality). Try to not use external (Internet) IP addresses due to attacks from the Internet network. Nevertheless, if you have to use an Internet IP address, later you will learn how to increase the security of your SSH.
#ListenAddress indicates that we do not want to use
IPv6 (line commented) and do not want to assign IPv6
to ::.
sshd_config 2nd part listing:
Protocol 2
# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024
SyslogFacility AUTH
LogLevel DEBUG3
Protocol and then the number 1 or 2. The second one is newer, so use it and comment all lines indicated for 1 (look at the three commented rows above for example).  This option selects the protocol version of SSH, and version 2 is more secure and has more features.
SyslogFacility and then AUTH, DAEMON, USER or others (see man page). It is for logging details. AUTH is sufficient for the security reason. The log file is /var/log/auth.log (absolute path). After logging in to your SSH, please list that file. You will learn more about the SSH connection and the security.  It is is recommended to copy your log file to analyze it later in case of break in or other factors associated with sshd.
LogLevel and then depth of debugging level indicated by INFO, ERROR, DEBUG3 (more at man page). DEBUG3 is the most detailed logging level, so it is recommended for use for security analyzing or to make sure the process is working
properly.
sshd_config 3rd part listing:
AllowUsers xyz007 backup John
AllowGroups wheel
LoginGraceTime 15
PermitRootLogin no
StrictModes yes
MaxAuthTries 3
MaxSessions 3
AllowUsers and then list of users separated with a space (almost always local users) xyz007, backup, John, or root (not recommended). The option gives the possibility to restrict connections to particular users. Try to use a nonstandard user, different than admin, administrator, sql, etc., to hinder attackers. Note: xyz007, backup and John are not default users after an installation, so you have to create the new ones and add them to the group wheel.
AllowGroups and then list of groups to have an access into the SSH connection. Listing is the same as for users.  Note: if the user is not listed in the AllowUsers option, but their group is listed in AllowGroups the user will not have the appropriate privileges to gain access into the SSH connection. Group wheel is the standard group for non-standard users, so if you even comment the AllowGroups user must be in the wheel group (just edit the file /etc/group and add the user to wheel group).
LoginGraceTime and then the number of seconds (i.e., 15) to successful log in. If you exceed the limit of seconds, the server drops your connection to inactive and you have to start to log in again. Note: 60 is equivalent to 60s, as well as 1m.
PermitRootLogin and then one of the values no, yes, or others (see man page). The name of PermitRootLogin explains everything.  Note: If the line is commented, that means that root log in is not allowed (recommended) to connect to SSH.
StrictModes and then one of the values no or yes. It is is recommended to set the value to yes, because sshd process checks the home directory and other user files permissions.
MaxAuthTries and then the number of tries to connect into the SSH connection. It is is recommended to set the value to less than 10, (i.e., 3). If an attacker tries to guess the password, or passphrase, then after 3 times of unsuccessful login attempts their connection is dropped.
MaxSessions and then the number (i.e., 3) of simultaneous connections independent of users. So xyz007, backup and John all logged in at the same time would prevent others from logging in. For strict security reasons you can set the value to 1. Log in and keep the SSH connection as long as your network stability allows you to stay logged in (desktop locking, terminal locking and prevent others attack on your client).
sshd_config 4th part listing (keys generation and usage is explained at PART 2):
AuthenticationMethods publickey, password
publickey,keyboard-interactive
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
AuthenticationMethods and then list of authentication methods (i.e., publickey, password publickey, keyboardinteractive).  It means that authentication will start step-by-step via publickey, after successful authentication via publickey it goes to password publickey and then at the end is keyboard-interactive (user’s password). You can use one of them, two or three in correct order (publickey before password publickey and keyboard-interactive), but publickey and password publickey are concatenated, so you have to use them together in that order.
RSAAuthentication and then one of the values no or yes. It is required to set yes when you set one of the authentication methods on public key and two below options as well.
PubkeyAuthentication and then one of the values no or yes. It is required to set yes if you want to use public/private key authentication.
AuthorizedKeysFile and then path to public key (i.e., .ssh/authorized_keys). Be informed that the path is not absolute but is relative and the root is user’s home directory. Note: set the file permissions on 400 or u=r,g=-rwx,a=-rwx using command chmod, regardless public keys can be known for everyone.
Note: these four above options are the main pack of the security planks to keep safe your SSH connections safe.
sshd_config 5th part listing:
PasswordAuthentication yes
PermitEmptyPasswords no
PasswordAuthentication and then one of the values no or yes. It is required to set the value to yes due to using a user’s password authentication method. Without yes, the SSH connection will be unsuccessful and then dropped.
PermitEmptyPasswords and then no or yes. For security reasons it is recommended to set the value to no. Note: no user from wheel group and other standard groups (your groups) should not have account without password. There are many non-standard (application) users without password, but shell/terminal logging in is denied or should be denied to them.
sshd_config 5th part listing:
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
In short: X11 should never be used in Unix, Unix-like, Linux systems until system is destined as a server. It decreases the system load and improves security. Professional and experienced OS terminal user is faster than OS window user.
sshd_config 6th part listing:
PrintMotd yes
PrintLastLog yes
PrintMotd and then one of the values no or yes. Option outputs the text from the file /etc/motd (absolute path).  It is useful to inform unprivileged user about restrictions and other information before trying to log in. Try to devise your own text info.
PrintLastLog and then one of the values no or yes. It is recommended to set the value to yes to see your own login information and client IP address then to verify it was what was expected.
sshd_config 7th part listing:
UsePrivilegeSeparation sandbox
PermitUserEnvironment no
UsePrivilegeSeparation and then three values to set no, yes or sandbox. It is recommended to use sandbox or yes. Both values separate process and the sandbox does a jail environment. It is more secure to prevent escalation privilege due to code corruption, attack other host or kernel attack surface etc. Example process listing below (Listing 1) with comments started at //.
PermitUserEnvironment and then one of the values no or yes. It is recommended to set the value to no to prevent bypass access restrictions (see man page).
sshd_config 8th part listing:
ClientAliveInterval 60
ClientAliveCountMax 10
ClientAliveInterval and then value of seconds (i.e., 60) in conjunction with ClientAliveCountMax use encrypted channel to drop the SSH connection due to an inactive user through 60*10=600 seconds. It is good to use it, but MaxSession and keeping a session by one user will not work. ClientAliveCountMax and then value of multiple ClientAliveInterval (i.e., 10).
sshd_config 9th part listing:
MaxStartups 5:15:30
Banner /etc/ssh/motd
MaxStartups and then numbers X:Y:Z (i.e., 5:15:30) which mean randomly dropping the unauthenticated concurrent connections: 5 – the maximum of concurrent unauthenticated connections made example by attacker (alone value or with other as begin, see man page); 15 – base for ratio of probability (15/100)*100%=15%; 30 – the maximum of concurrent unauthenticated connections.  Note: It is not the same as MaxSessions. MaxSession works after authentication and MaxStartups works before authentication. It is good to set it for more than MaxSessions due to zombie processes that could take the socket for new connections.

Banner and then the absolute path to the text file (i.e., /etc/ssh/motd). Functionality the same that PrintMod has.

Please look at the screen shot (Listing 2) of the successful SSH connection. First the banner is PrintMotd and the second one, big is Banner (generated by banner application).  There is an AuthenticationMethods order starting from “Authentication with public key with passphrase for that key” and then “user’s password authentication”. You can find logging in details at the /var/log/auth.log or at another file you set. You can see the last login details and system details as well. If you do not want to see/show the system info, just delete the line from /etc/motd file or change it to something else, (i.e., fake OS). You see MATRIX and Unlock key text also. This application is my own and you can try it by downloading from www.iptrace.pl (go to Download and click on Locker). Application is free of charge and based on the BSD License. Any suggestions and errors about the Locker please send via e-mail locker@iptrace.pl.

Keys generation and usage
We have to generate both private and public key pairs. Next, we have to set up our OpenSSH server and then client to use it.
The server side stores the public key because from the server side it is a “public” machine. Public means, other administrators (especially roots) have access to your home directory and is not advisable to keep the private key there. You are the owner of this key, so you have to keep it safe like the key to your house.
Let’s start to generate the key pair with 4096 bits of RSA. It is better to generate the key pair logged in as the owner of the keys, because the default keys location will be proper and the owner of the files will appropriate.
# ssh-keygen -b 4096

The output should look like Listing 3. Note: You can define the passphrase to improve the security. It is referred to password publickey in the AuthenticationMethods option. Setting the passphrase is not strictly required, but it is a good security approach. Sometimes the passphrase is omitted when users login via other SSH clients, especially Unix/Linux systems, just for one command to speed up these procedures.
So we have two keys in the .ssh directory placed in user’s home directory. The public key is named id_rsa.pub and the private key is named id_rsa. Rename the public key to authorized_keys (referred to AuthorizedKeysFile option) and change the permissions to 400. Changes on the server side have been completed.
Let’s look closer at the client side configuration. At first, we have to copy data from the private key file to the standard, text file. The file data is shown in Listing 4, you will have more data for the same 4096 bits, but I have truncated it to look better.

The next step is to select the data and copy to the file placed in the client side, example named ssh_key.txt.  Note: the client side in this instance is based on MS Windows, WinSCP and Putty.
Now we have to regenerate our private key for Putty recognition. For this case we use one of the WinSCP ap-ps. It names PuTTYgen. So, run the application and click on the Load, to load your private key. During loading the file, the application asks for a passphrase. When complete (Figure 1), you will see the following window. Click Save for the private key using a ppk extension.

At the end of our tour, we have to configure Putty to use our new private key. Run Putty and then go to category Connection->SSH>Auth then you will see the field Private key file authentication, click Browse and get your new private key file. Insert your server IP address and other features and save your session for future use.

Conclusions
Look at man pages of sshd and sshd_config to learn more about other interesting options for SSH connections.
SSH is a great and a rich protocol and can be used not only for SSH connections (terminal connections), but for files transfer, known as an SFTP, or for VPNs tunneling.  The OpenSSH configuration works great for SFTP connections using mentioned WinSCP application. WinSCP is easy and similar to Putty configuration.
You shall find or devise a lot of authentication methods, but one that is interesting, is known as one time password OTP. You can find more information about it by searching the Internet. Try to use it in conjunction with e-mail, SMS or token. Good Luck!
In the next series you will find out about:
OTP – one time password to beef SSH connections up.
VPN tunnelling – creating Virtual Private Networks using OpenSSH
SFTP – known as SSH File Transfer Protocol to opposite of a standard FTP

About the Author
Arkadiusz Majewski comes from Poland. He has 15 years experience with ICT technologies, including 15 years of IT networks, 10 years of BSD systems and MS Windows Server solutions. He also has 5 years experience with programming languages and Telco solutions. He is interested in security on all business and ICT levels. In his free time he reads ICT books, deepens his knowledge about science (math, physics, chemistry). His hobby is cycling and motorization. He is a graduate of Warsaw Information Technology, under the auspices of the Polish Academy of Sciences.
Feel free to contact the author via e-mail: bsd.magazine@iptrace.pl.

This article was re-published with the permission of BSD Magazine.  To Learn More about iXsystem’s commitment to open source check us out here:   https://www.ixsystems.com/about-ix/