Most common custom SSH Configurations of the OpenSSH Server

The Openssh set of utilities let us create secure, encrypted connections between machines. In this tutorial we will take a look at some of the most useful options we can use to change the behavior of sshd, the Openssh daemon in order to make your Linux system administration job easier.

In this article we assume the existence of an already running and accessible server. If you want to know more about Openssh installation, you can take a look at this article on how to install SSH server on Ubuntu Linux.

In this tutorial you will learn:

  • How to customize the behavior of the sshd daemon by manipulating options in the main ssh config file /etc/ssh/sshd_config
  • How to change the default port(s) used by the server
  • How to change the address the server listens to
  • How to change the maximum SSH login time
  • How to allow or deny login as root
  • How to change the max login attempts and maximum number of session opened
  • How to display a message when user tries to authenticate to the server
  • How to Enable/Disable password and pubkey authentication
  • How to Enable/Disable HostBasedAuthentication
  • Enabling/Disabling X11 Forwarding

Software Requirements and Conventions Used

Software Requirements and Linux Command Line Conventions
Category Requirements, Conventions or Software Version Used
System Distribution-independent
Software No additional software is required to follow this tutorial apart from Openssh
Other A running Openssh server
Conventions # – requires given linux commands to be executed with root privileges either directly as a root user or by use of sudo command
$ – requires given linux commands to be executed as a regular non-privileged user

The sshd daemon config file

By default sshd, the Openssh daemon, reads its configuration from the /etc/ssh/sshd_config file. A different file path can be specified by using the -f option when launching the daemon. There are many options we can change to alter the behavior of the daemon. While it’s not possible to mention all of them here, we will see some of the most commonly used ones and what we can obtain by changing their values. Every time an option is changed, to make the changes effective the daemon should be restarted. When using systemd, the command to run is:

$ sudo systemctl restart sshd

Changing the port(s) used by the server

This is what is called a security through obscurity measure: by default the sshd daemon listens on port 22. Changing the port in use does not improve the security per se, since it is trivial to make a port scan and see what ports are in use by a machine. More than often, however, brute force login attempts just targets the default port, so modifying the port in use can help. To instruct the daemon to listen to a specific port, we use the Port option and provide the port number:

Port 1024


Multiple occurrences of the option can be provided: the server will listen on all the specified ports. Before restarting the ssh server to make the change effective,  it’s really important to modify the firewall rules accordingly to the change. On the client side, to connect using a specific port, we must specify the port number by using the -p option (short for –port). For example, to login using port 1024 we would write:

$ ssh -p 1024 egdoc@feanor

To avoid having to specify the port each time we connect to the server, we can setup an entry for it in the ~/.ssh/config file (we may have to create it, since it doesn’t exist by default and we must make it accessible only by the user), as in the example below:

Host feanor
    HostName 192.168.0.39
    Port 1024

This way, each time we will try to ssh into a matching Host (feanor in this case) the parameters specified in the related stanza of the ssh config file will be applied automatically.

Changing the address the server listens to

In addition to the port the sshd daemon listens to, we can also change the listen address. By default the server listens on all local addresses. Examples of the syntax to use with this option can already be found in the ssh configuration file:

#ListenAddress 0.0.0.0
#ListenAddress ::

We can specify the address in one of the following ways:

  • host|IPv4 address|IPv6 address
  • host|IPv4 address:port
  • host|IPv6 address:port

The option to use is called ListenAddress Multiple occurrences of the options are permitted, in order to specify multiple addresses. We can use IPv4 or IPv6 address, and optionally specify the port to be used. If we don’t specify a port the sshd daemon will listen on the port(s) specified with the Port option we saw above.

Changing the maximum login time

We can configure the Openssh daemon to disconnect after a specified amount of time if the user does not successfully log in. In this case the option we want to change is called LoginGracetime. All we have to do is to provide the time limit value, for example:

LoginGracetime 2m

The default value for this option is 120s (seconds)

Allow or deny login as root

By using the PermitRootLogin option we can establish if the sshd daemon should allow the root user to login directly. The option accepts one of these values:

  • yes
  • no
  • prohibit-password
  • forced-commands-only

The first two values are pretty self-explanatory. When using yes the root user is allowed to login via ssh, when using no this possibility is denied. The prohibit-password and forced-commands-only values are more interesting.

When the former
is used as the value of the PermitRootLogin option, password and keyboard interactive logins are disabled, but the root user can login using a public key. If forced-commands-only is used, instead, root login via public key authentication is allowed but only if a command option is specified in the authorized key. For example:

command="ls -a" ssh-rsa [...]


Above we specified ls -a as the command for the ssh key that will be used by root. This way when connecting using the key, the command will be executed, and then the connection to the server will be closed. Let’s verify it (here I assumed the key is already in place on the client and has been authorized on the server):

$ ssh root@feanor
Enter passphrase for key '/home/egdoc/.ssh/id_rsa':
.  ..  .bash_history  .bashrc  .profile  .ssh  .vim  .viminfo
Connection to feanor closed.

Changing the max login attempts and maximum number of session opened

Another two parameters we may want to change is the number of attempted login per connection, and the number of  opened shells, login or subsystem session allowed. We can change the former parameter by using the MaxAuthTries option, providing the number of allowed attempts (default value is 6). The  latter, instead, can be  modified by using the MaxSessions option. This option also takes an integer value, the default being 10.

Display a message when user tries to authenticate to the server

We can use the Banner option to specify a file containing some text we want to send to the user before he authenticates to the server. The default value for the option is none, so no banner is displayed. Here is an example. The /etc/ssh/banner file we created contains some text we use as a message. If we set the option as below:

Banner /etc/ssh/banner.txt

When we try to login we get the following result:

$ ssh egdoc@feanor
###############################
#         Test Banner         #
###############################
egdoc@feanor's password:

Enabling/Disabling password and pubkey authentication.

The sshd daemon provides multiple way to authenticate users. We can choose to enable or disable authentication by password or by public key using respectively the PasswordAuthentication and PubkeyAuthentication options. By default both options are usually set to yes: this means that the user can connect to the server by providing his password and also by using a public key he owns (the key can also be protected by a password). To disable one of the two options we simply use no as a value. For example, if only want to allow login by public keys we can set:

PasswordAuthentication no

This way only users who have a public key contained in the authorized keys file will be able to login in to the server. The authorized keys file is the file which contains the allowed public keys. By default the file is .ssh/authorized_keys in the home directory of the user on the server, but this can be changed using the AuthorizedKeysFile option and specifying an alternative file, providing either an absolute or a relative path. When a relative path is used, it is considered as relative to users home directory. The option can also be set to none: this way the server will not search for public keys in files.

Enabling/Disabling HostBasedAuthentication

The Openssh server can be set to accept host-based authentication. When using this type of authentication an host authenticates on behalf of all or some of its users. The option is set to no by default. Setting the option to yes is not enough to make host-based authentication work.

Enabling/Disabling X11 Forwarding

The X11 window system has a client-server architecture: the clients are the many graphical applications requesting connection to the server which manages displays. The X11 server and its clients often run on the same machine, but this it’s not necessary. It’s possible to access a remote X11 server via a dedicated but unsecure protocol. Openssh let us run the connection securely, creating an encrypted tunnel. The option that controls this behavior is X11Forwarding. The feature is generally disabled by default, so it is set to no.

We must set the option to yes if we want to take advantage of it. On the client side, we enable the feature by using the -X option from the command line, or set ForwardX11 to yes in the client configuration file. For example, say we have X11 running on the remote machine; we want to use the ssh connection to launch the “pluma” application (a lightweight text editor) and control it using X11Forwarding. We run:

$ ssh egdoc@feanor -X pluma


The program will be launched. In the title bar, clearly we can see that it is running on “feanor”, which is the name of the remote machine.


x11-forwarded-app

X11 forwarding in action

Conclusion

In this tutorial we saw what is the default sshd daemon configuration file and we learned how we can use an alternative one by specifying its path with the -f option when starting the service. We also took a look at some of the most useful options we can use in said file to change the behavior of sshd. We saw how to allow or deny password-based and public-key based authentications; how to enable or deny root login; how to enable or disable the X11 forwarding feature and how to make the server display a message when a user tries to authenticate on it.

We also saw how to specify the maximum allowed login attempts per connection and how to change the addresses and ports the server listens to. To know more about the possible server configurations, please consult the manual page for sshd and for the sshd_config configuration file.



Comments and Discussions
Linux Forum