Ubuntu Wiki

Introduction

This guide introduces some advanced measures for increasing the security of a standard Ubuntu OpenSSH server installation beyond the security offered by default settings. This guide will discuss particular server-side configuration directives, and explain the process of using Rivest Shamir Adleman (RSA) algorithm keys for logging into an OpenSSH server versus plain passwords. Additional resources for OpenSSH are referenced in the Resources section of this guide.

Target Audience

To properly implement the suggestions in this guide, the reader should be a user of Ubuntu who is comfortable with the use command-line applications, using the Bourne Again SHell (bash) environment, and editing system configuration files with their preferred text editor application. Additionally, the reader should know how to start, and stop system daemons, and have a basic understanding of the OpenSSH package.

About OpenSSH

OpenSSH is a freely available version of the Secure Shell (SSH) protocol family of tools for remotely controlling a computer, or transfer of files between computers. Traditional tools used to accomplish these functions such as telnet, or rcp are insecure, and transmit the user's password in cleartext when used. OpenSSH provides a server daemon, and client tools to facilitate secure, encrypted remote control, and file transfer operations, effectively replacing the legacy tools.

OpenSSH Server (sshd)

The OpenSSH server (sshd) is typically run as a standalone daemon, though it may also be called into service on an as-needed basis by launching from the Internet Daemon (inetd) or the Internet Daemon's more modern, and secure equivalent, xinetd. The OpenSSH server is configured via the directives found in the file /etc/ssh/sshd_config. This section of the guide will discuss the default settings in this file, and how some of them may be modified for more secure operation of sshd. The settings will appear here first as configured by default, and in italics (such as Port 22) with a brief explanation of the setting, followed by a suggested setting in bold (such as Protocol 2) presented for increased security.

To change the configuration of sshd in your OpenSSH installation, first make a backup of your original sshd_config file using the following command in a terminal / at a shell prompt :

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.original

You may optionally elect to protect the original file from accidental overwriting by using the command:

sudo chmod a-w /etc/ssh/sshd_config.original

Now that you've backed up the original sshd_config file, you may modify the sshd_config file by replacing the default value for a setting as shown, with the suggested setting. In order for any of the settings you change to have any effect, you must save the /etc/ssh/sshd_config file, and restart sshd with the following command:

sudo /etc/init.d/ssh restart

Suggested OpenSSH Server Settings

The default sshd_config which is used with Ubuntu's OpenSSH package is more secure than that found in other distributions of GNU/Linux, but there are changes which can enhance this level of security.

Logging

|| LogLevel INFO ||

The default settings enable sshd logging to the AUTH facility of syslog, at the INFO level. If ssh will be the primary remote access mechanism used for access to your Ubuntu computer, you should consider raising the logging detail level to VERBOSE, so you will have the most details available about all ssh logins, and attempted logins.

|| LogLevel VERBOSE ||

Now all the details of ssh logins, and potential logins will be recorded into the AUTH context of syslog in a verbose manner.

Authentication

|| LoginGraceTime 120 PermitRootLogin yes ||

By default Ubuntu's configuration of the OpenSSH sshd server allows for 120 seconds (two minutes) from the time the login prompt is displayed until a user must begin the login process before the connection is dropped by the sshd server. Also, the root user is permitted to login via ssh. While Ubuntu disables the root user by default in the system, if this account is mistakenly enabled, and OpenSSH installed, then the root user may potentially be allowed to login remotely. A definite, security no-no. Being that ssh may be the primary remote access method for accessing your Ubuntu computer(s) we should not let the server wait so long for a login, and we should certainly not be allowing root to login.

|| LoginGraceTime 20 PermitRootLogin no ||

Now the sshd server will only wait twenty (20) seconds for a user to begin the login process before disconnecting the remote. This may aid in thwarting automated, or brute force ssh attacks, and the root user is no longer allowed to login remotely.

|| X11Forwarding yes ||

If the computer is a traditional server, and is not providing X11 services in any form, (eg. an E-Mail, or Web server), then X11 tunneling should be disabled to remove a potential vector of future attack.

|| X11Forwarding no ||

Now X11 forwarding will not be available from the sshd server.

|| #Banner /etc/issue.net ||

Displaying an UN-welcome banner is a good idea for security. It informs the curious, or deliberate unauthorized visitor to your OpenSSH server that it is for authorized purposes only. In order to successfully prosecute an attacker, or other unauthorized party who gains access to your server via sshd, having a pre-login banner in place helps a great deal.

|| Banner /etc/issue.net ||

Now the banner is enabled. Create the actual banner file using the following process, and example content for the banner:

Using sudo, and your favorite editor, create the file /etc/issue, and place the following in it as a starting point for a pre-login warning banner:

|| ***************************************************************************

• NOTICE TO USERS

This computer system is the private property of its owner, whether individual, corporate or government. It is for authorized use only. Users (authorized or unauthorized) have no explicit or implicit expectation of privacy.

Any or all uses of this system and all files on this system may be intercepted, monitored, recorded, copied, audited, inspected, and disclosed to your employer, to authorized site, government, and law enforcement personnel, as well as authorized officials of government agencies, both domestic and foreign.

By using this system, the user consents to such interception, monitoring, recording, copying, auditing, inspection, and disclosure at the discretion of such personnel or officials. Unauthorized or improper use of this system may result in civil and criminal penalties and administrative or disciplinary action, as appropriate. By continuing to use this system you indicate your awareness of and consent to these terms and conditions of use. LOG OFF IMMEDIATELY if you do not agree to the conditions stated in this warning.

**************************************************************************** ||

Save the file, and then create a symbolic link to the /etc/issue.net file using the following command:

sudo ln -s /etc/issue /etc/issue.net

Now when you've restarted your sshd, all logins will be met with the above warning, followed by the login prompt. All unauthorized visitors will receive a clear message that your computer is for authorized use only, and that unauthorized use is not welcome. The above warning banner was created from a modified Department of Defense warning banner, and is completely adequate for professional, and personal use.

Additional Configuration Tips

The following are some extra hints, and tips for configuring a more secure OpenSSH installation. These tips make use of some directives not contained within the default Ubuntu sshd_config, and mention other ideas for enhancing the security of your OpenSSH installation.

Allowed and Denied Users and Groups

You may use certain directives in your sshd_config to allow, or deny login with ssh by certain users, or groups. This ability provides more granular control over who has access to your Ubuntu computer(s) via ssh.

For example, if you wished to allow only the users jhendrix, and svaughan to login via ssh, you could use the AllowUsers directive in your /etc/ssh/sshd-config file as such:

|| AllowUsers jhendrix svaughan ||

If you didn't mind all users logging in via ssh, with the exception of the users wgates, or sballmer then you could add the DenyUsers directive to your /etc/ssh/sshd_config in a similar manner as such:

|| DenyUsers wgates sballmer ||

Finally, in another example, you could configure your OpenSSH server so that only users belonging to a certain system group would be allowed to login via ssh. In this example, we'll perform all the steps required to allow ssh logins only to users who are members of the group sshlogin

sudo addgroup --gid 450 sshlogin

sudo adduser [username] sshlogin

Finally, edit your /etc/ssh/sshd_config, and add an AllowGroup directive as such:

|| AllowGroup sshlogin ||

Restart sshd, and only users who belong to the group sshlogin will be allowed to login to your Ubuntu computer via ssh.

Start sshd on a Different Listening Port

In light of the recent rise in numerous automated ssh scanning, and brute force attacking tools, many users, and administrators of systems with OpenSSH installations are deciding to use a non-standard listening TCP port for sshd. The standard sshd listening port is tcp/22, and the brute force scanning/attacking tools look for daemons running on this port.

Though migrating away from plain password ssh logins to key-based logins as discussed in the next section of this guide significantly minimizes the chances of an automated tool guessing a valid login on one of your systems, some feel that adding one more layer of obscurity may possibly enhance security even more. If you've considered the ramifications of running your sshd on a non-standard port, for example the constant need to use -p or -P switches with the various OpenSSH tools, or the modification of /etc/ssh/ssh_config to correct for the port change in a more permanent manner, and are accepting of those compromises, then changing the listening port of sshd is very trivial.

Simply add one, or more Port directives to your /etc/ssh/sshd_config file, as such:

|| Port 2222 ||

If you wished to have sshd listen on both ports tcp/22, and tcp/2222, for example so that internal LAN connections could be made in the traditional manner, but outside connections could be answered on port tcp/2222 without the need for firewall rules, and the like, then simply add both directives to /etc/ssh/sshd_config:

|| Port 22 Port 2222 ||

Don't forget to restart your sshd with the command:

sudo /etc/init.d/ssh restart

in order for the changes to take effect.

RSA Key-Based SSH Logins

The use of public/private key pairs for authentication is but one of several modes of authentication usable with OpenSSH, such as plain password (the default with Ubuntu) and Kerberos tickets. Key-based authentication has several advantages over password authentication, for example the key values are much harder to brute-force, or guess than plain passwords, and keys are a metaphor for their physical counterparts, and therefore may impart a degree of portability not possible with plain passwords. Using key based logins with ssh is generally considered much more secure than using plain password logins.

attachment:IconsPage/IconNote.png NOTE: While it is possible to generate a set of RSA keys for use with OpenSSH which do not have a password assigned to them, for easy, passwordless logins via ssh, this guide does not describe, or endorse such use as it is very insecure. If your passwordless keys fall into the wrong hands, then so does your authentication, thereby allowing easy compromise of all systems which permit the keys. In certain situations, such as insecure clustered environments, completely passwordless logins my be desirable, but again this guide does not explain the process of providing such keys.

This section of the guide will explain the process of enabling ssh key based logins, generating a set of public/private RSA keys, and using them for logging into your Ubuntu computer(s) via OpenSSH.

Generating RSA Keys

The first step involves the generation of a set of RSA keys for use in authentication. Typically, you would do this on the machine you intend to use for logging into all other machines, but this does not matter much, as you can always move the keys around to other machines as needed. To generate a set of RSA public/private keys, use the following command:

b@tsh:~ ssh-keygen -t rsa

You will be prompted for a location for saving the keys, and a passphrase for the keys. When choosing the passphrase for the keys, pick a very strong passphrase, and remember, or note it in a secure place. This passphrase will be required to use the keys every time you need to login to a key-based system:

|| Generating public/private rsa key pair. Enter file in which to save the key (/home/b/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/b/.ssh/id_rsa. Your public key has been saved in /home/b/.ssh/id_rsa.pub. ||

Congratulations! You now have a set of keys. Now to make your systems allow you to login with them.

Locating the Keys on Remote Computers

Assuming the remote Ubuntu computers you wish to use the keys for have running ssh daemons already, then locating your public portion of the keypair on those machines is quite simple. For example, if you'd like to begin using key-based logins on a remote machine named madison, and madison is running sshd, and reachable by name on your network, simply use the ssh-copy-id command to properly locate your key:

ssh-copy-id -i ~/.ssh/id_rsa.pub b@madison

Testing the Login

Next, you need to test the login, by attempting a connection to the machine and using yur passphrase to unlock the key:

ssh b@madison

You will be prompted for the passphrase for your key:

|| Enter passphrase for key '/home/b/.ssh/id_rsa': ||

Enter your passphrase, and provided madison is configured to allow RSA key-based logins, you should then be logged in as usual.

attachment:IconsPage/IconNote.png NOTE: The examples above were just that...examples! Substitute the user name b with your actual user name in order to increase your chances of success.

It Doesn't Work!

If you are not prompted for the passphrase, and instead get just the

|| b@madison's password: ||

prompt as usual with password logins, then read on. There are a few things which could prevent this from working as easily as demonstrated above. On default Ubuntu installs however, the above examples should work. If not, then check the following condition, as it is the most frequent cause:

On the remote computer, ensure that the /etc/ssh/sshd_config contains the following lines, and that they are uncommented;

|| RSAAuthentication yes PubkeyAuthentication yes ||

If not, add them, or uncoment them, restart the sshd, and try logging in again. If you get the passphrase prompt now, then congratulations, you've just logged in with an RSA key!

Where to From Here?

If you've been successful in establishing RSA key-based logins, you may wish to make this the only acceptable form of authentication on your Ubuntu computer(s) by disallowing plain password authentication entirely. Taking this route will ensure that automated brute-force scanners, and attack tools have a much harder time with your publicly exposed systems. Be forewarned however, if you lose your keys, you may find yourself locked out!

To instruct your sshd to disallow plain password authentication, simply use sudo and your favorit editor to edit /etc/ssh/sshd_config, and change the following directive:

|| #PasswordAuthentication yes ||

by uncommenting it, and changing yes to no:

|| PasswordAuthentication no ||

Save the file, and restart sshd to disable plain password authentication.

attachment:IconsPage/IconDialog-Warning1.png WARNING : For the second time, if you disable plain password authentication, and do not have a working key-based login, or lose your keys, you will be LOCKED OUT of your remote machine. Of course, you can still login via console at the machine physically, but this may not be so easy if your remote computer is 500 miles away! You have been warned again!

Resources

Additional resources pertaining to the advanced configuration of OpenSSH for enhanced security appear below.

Local System Resources

• man sshd - manual page for the sshd server daemon

• man sshd_config - manual page for the sshd_config configuration file

• man ssh-copy-id - manual page for the ssh-copy-id application

• man ssh-keygen - manual page for the ssh-keygen application

• /etc/ssh/sshd_config - the OpenSSH Secure Shell Daemon (sshd) configuration file

WWW Resources

[http://www.openssh.org/ OpenSSH Website]

[http://www.debian-administration.org/articles/87 Keeping SSH access secure]

[http://www.debian-administration.org/articles/152 Password-less logins with OpenSSH]