This is the third blog post in the series of blog posts on the Secure Shell aka SSH. You can find index here. In the last post, we discussed how to copy ssh public key to the remote server and then discussed few local options to create and customize ssh sessions. We also discussed about the usage of ssh-agent. In this blog post, we’ll discuss how we can customize the SSH session using some of the popular server side configuration options. Using these options can shape the way the connection is established and connection experience for the ssh clients.

SSH Server configuration files

The SSH server actually reads several configuration files. The sshd_config file specifies the locations of one or more host key files (mandatory) and the location of authorized_keys files for users. It may also refer to a number of other files. The startup file, sshd_config file may be stored in some other location or the SSH server can be started using a different configuration file as well. In such a case, file name can be supplied using -f option. Some organizations run multiple SSH servers at different port numbers, specifying a different configuration file for each server using this option.

Cryptographic Policy

Below table summarizes some of the cryptographic algorithms, which are used to establish session between SSH server and client:

• Ciphers – aes128-ctr,aes192-ctr,aes256-ctr
• HostKeyAlgorithms – ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss
• KexAlgorithms – ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha256
• MACs – hmac-sha2-256,hmac-sha2-512,hmac-sha1

Authorized Keys file location

This is one of the very less used options as most organizations, choose to not set this value. This makes the file ~/.ssh/authorized_keys present under respective user account as the default file location. However, if need be, the keys can be stored under one common directory on the server using the AuthorizedKeysFile option:

AuthorizedKeysFile /etc/ssh/authorized-keys/%u

Disabling Root Login

Generally, the root account has no password at all. There is no good reason to allow the remote login for the root user using SSH. If users need to perform certain tasks or run certain scripts, where root access may be warranted, they can use a privilege escalation method such as sudo or dzdo.

To disable root login, open the default configuration file, /etc/ssh/sshd_config for editing and search for a directive called PermitRootLogin. If its commented, uncomment it and change the value to no:

PermitRootLogin no

Save and close the file. To implement your changes, restart the SSH daemon.

Display Login Banner

Many enterprises, especially in the government, may want to print a login banner with legal warnings before asking for a password. Using the directive, Banner, they can configure SSH dameon to display the contents of a particular file as the banner:

Banner /etc/banner

Changing the default Port for listening connections

SSH is wildly subjected to login attacks on the default port 22 using the automated bots. If your server is publicly hosted, its advisable to change the default port, in order to reduce the number of unauthorized login attacks. To change the port, that SSH server will listen to for incoming connections, one can use the Port directive. To run server on customized port, define the port number after the Port directive:

# Port 22
Port 9219

Save and close the file. To implement your changes, restart the SSH daemon.

Disabling Password Authentication

As part of the security practices, password based SSH logins can be completely disabled, in order to reduce the unauthorized login attempts. This will prevent any user from signing in with SSH using a password. This can be done by setting the PasswordAuthentication to no:

PasswordAuthentication no

Save and close the file. To implement your changes, restart the SSH daemon.

Disable Port forwarding and Tunneling

Enterprises would generally want to prevent port forwarding on their servers, unless expressly needed for tunneling legacy applications. There is substantial risk that users will use SSH tunneling to open backdoors into the organization through the firewall to get access to work machines from home. This technique is widely known and used for gaining unauthorized access.

Even if port forwarding is disabled, there is still the possibility of a user running their own SSH server or having their own laptop run one. This is discussed in more detail in one of the later posts, in this series.

Port forwarding and tunneling can be disabled by using the below directives:

AllowTcpForwarding no
AllowStreamLocalForwarding no
GatewayPorts no
PermitTunnel no 

Configure max authentication tries

This can be used to specify the maximum number of authentication attempts permitted
per connection by using the MaxAuthTries directive. Once the number of failures reaches half this value, additional failures are logged. The default is 6.

Above are some of the most common used sshd configuration options. Full listing of all available configuration options can be found on the sshd Config Manual Pages.

In next blog post, we’ll discuss some of the client side configuration options available for SSH.