Introduction

SSH replaces older, insecure programs like telnet, rlogin, and FTP. These older applications transmit passwords across the Internet without encryption, meaning the password could easily be stolen.

If you want to securely connect to your machine from a remote computer, even a computer running another operating system like Mac OS or Windows, then you need to install the openssh-server package from the main repository. Installing software is discussed in InstallingSoftware.

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.

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

About OpenSSH

OpenSSH provides secure remote access to your computer, allowing you to run command line and graphical programs, transfer files, and use a "port forwarding" capability to securely tunnel other protocols through firewalls and untrusted networks.

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 notoriously insecure, and transmit the user's password in clear-text when used. OpenSSH provides a server daemon, and client tools to facilitate secure, encrypted remote control, and file transfer operations, which effectively replace the legacy tools with modern equivalents.

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 default settings are shown first (in italics, such as Port 22) with a brief explanation of the setting, followed by suggested settings (in bold, such as Protocol 2) presented for increased security.

Configuration

To change the configuration of sshd in your OpenSSH installation, first make a backup of your original /etc/ssh/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

If the file is missing it means that OpenSSH Server is not installed. To install choose the file openssh-server from the repositories. Notice that a file ssh_config exists in the same directory, but don't change it since this file belongs to the client version of OpenSSH.

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

Backing up configuration files in this manner is considered best practice for the administration of your Ubuntu GNU/Linux system. If for some reason you need to refer to the original configuration, you'll have it handy, and if you make a mistake, and render an application inoperable through misconfiguration, you can always fall back on the original file, provided you've backed it up prior to altering it.

Now that you've backed up the original /etc/ssh/sshd_config file, you may modify the 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 /etc/ssh/sshd_config which is used with Ubuntu's OpenSSH implementation is more secure than that found in many other distributions of GNU/Linux, but there are changes which can enhance this level of security even further, and those changes are suggested here. Some of these changes may not be suitable to your particular situation. Use the settings which offer the best trade-off between security, and usability for your situation.

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 are typically configured to look for daemons listening on this port.

Though migrating 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:

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 Network Address Translation rules, and the like in your router, then simply add both directives to /etc/ssh/sshd_config:

Don't forget to save the file, and restart your sshd with the command:

sudo /etc/init.d/ssh restart

in order for the changes to take effect.

Logging

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 of the LogLevel directive to VERBOSE, so you will have the most details available about all attempted, and successful ssh logins.

Now all the details of ssh logins, and potential logins will be recorded into the AUTH context of your /var/log/auth.log logfile in a verbose manner.

Testing the server

Once you have installed the server, go to a command-line and type:

ssh localhost

You should be prompted to type your password, and you should get another command-line when you type your password in. If this works, then your SSH server is working properly. To leave the SSH command-line, type:

exit

If you have a local network (such as a home or office network), try logging in from one of the other computers on your network. If nothing happens, you might need to tell your computer's firewall to allow connections on port 22.

Finally, try logging in from another computer elsewhere on the Internet - perhaps from work (if your computer is at home) or from home (if your computer is at your work). If you can't access your computer this way, you might need to tell your router's firewall to allow connections from port 22, and might also need to configure Network Address Translation.

Logging in from other computers

Although SSH has many uses, its main job is to provide access to a command-line over a network. Even if you are installing SSH for completely different reasons, it's best to get command-line access access before you try anything more complicated.

From Unix-like systems (including Mac OS X)

Using the command-line

All modern Unix-like systems (Linux, OS X, BSDs, and others) include a command-line ssh client. To login to your computer from a Unix-like machine, go to a command-line and type:

ssh <username>@<computer name or IP address>

For example:

ssh joe@laptop

or:

ssh mike@192.168.1.1

You should get the same password prompt as before (or be told you can't log in, if passwords are disabled).

Tip: Keep Alive

Your ssh session will automatically log out if it is idle. To keep the connection active (alive) add this to /etc/ssh/ssh_config on the machine you are logging in from:

ServerAliveInterval 120

This will send a "keep-alive" signal to the server every 120 seconds.

Transferring Files Remotely With SSH

Another important function of SSH is allowing secure file transfer using SCP and SFTP.

Secure Copy (scp)

Just as all modern Unix-like systems have an SSH client, they also have SCP and SFTP clients. To copy a file from your computer to another computer with ssh, go to a command-line and type:

scp <file> <username>@<IP address or hostname>:<Destination>

For example, to copy your TPS Reports to Joe's Desktop:

scp "TPS Reports.odw" joe@laptop:Desktop/

This will copy TPS Reports.odw to /home/joe/Desktop, because SCP uses your home folder as the destination unless the destination folder begins with a '/'.

To copy the pictures from your holiday to your website, you could do:

scp -r /media/disk/summer_pics/ mike@192.168.1.1:"/var/www/Summer 2008/"

The -r (recursive) option means to copy the whole folder and any sub-folders. You can also copy files the other way:

scp -r catbert@192.168.1.103:/home/catbert/evil_plans/ .

The '.' means to copy the file to the current directory. Alternatively, you could use secret_plans instead of '.', and the folder would be renamed.

Secure FTP (sftp)

Finally, if you want to look around the remote machine and copy files interactively, you can use SFTP:

sftp linus@kernel.org

This will start an SFTP session that you can use to interactively move files between computers.

SSHFS

SSHFS is a recent addition to Linux that allows you to make a remote filesystem available over SSH act as if it was inside a folder on your own system. See SSHFS for details.

GNOME

Click Places -> Connect to Server. Select SSH for Service Type, write the name or IP address of the computer you're connecting to in Server, the user you'd like to connect as in User Name, and a name for the connection if you wish.

Files can be copied by dragging and dropping between this window and other windows.

KDE

Open Konqueror, and in the address bar type:

fish://username@server_address

Files can be copied by dragging and dropping them between this window or tab and to other windows or tabs.

Authentication

By default, Ubuntu's configuration of the OpenSSH 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 terminated by sshd. This behavior is controlled by the LoginGraceTime directive.

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 denial of service style attacks against sshd.

If you do not want people logged into the computer through SSH to be able to run graphical programs (which are displayed on their computer through the SSH tunnel), then you can disable X11 tunneling by modifying the X11Forwarding directive to remove a potential vector of attack, particularly to connected ssh clients.

Now X11 forwarding will not be available from your sshd.

Warning: Disabling X11 forwarding is not recommended. If the server is to be used for LTSP, then do not disable X11 Forwarding, or you'll break support for such capabilities!

Displaying an UN-welcome banner, via the Banner directive is a good idea for security. It informs the curious, or deliberate unauthorized visitor to your OpenSSH server that remote access to your computer is for authorized purposes only, and by authorized users only.

Having a pre-login banner in place helps a great deal with successfully prosecuting an attacker, or other unauthorized party who attempts to gain access to your server via sshd.

Now that the banner display is enabled in /etc/ssh/sshd_config, create the actual banner file using the following process, and example content:

Using sudo, and your favorite editor, create the file /etc/issue, and place the following text 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

Once you've restarted sshd, all login attempts 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 U.S. Department of Defense warning banner, and is adequate for professional, and possibly more than adequate for personal use.

As a side note, all local console logins will also display this message from the file /etc/issue, meaning that even those using the machine at the physical level will receive the warning as well. If this is not the behavior you desire, then place the banner content in an /etc/issue.net file rather than making a symbolic link from /etc/issue. With no text in /etc/issue, the warning will be presented only to those attempting to access the system remotely.

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 /etc/ssh/sshd_config file to allow, or deny login with ssh by certain users, or groups. This ability provides more fine-grained 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:

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, like this:

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

Replace '<username>' in the example above with the actual username you wish to add to the sshlogin system group. Finally, edit your /etc/ssh/sshd_config, and add an AllowGroups directive as such:

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

Kerberos based SSH Logins

In order to enable users to login to your server using their kerberos tickets you need a working Kerberos setup. After you have set-up the Kerberos system and can obtain your tickets on the SSH client and server, set the following options in /etc/ssh/sshd_conf:

# Kerberos options
KerberosAuthentication yes
#KerberosGetAFSToken no
KerberosOrLocalPasswd yes
KerberosTicketCleanup yes

# GSSAPI options
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

The SSH server needs a keytab entry for the principal host/sshserver.yourdomain.com/YOURDOMAIN.COM (replace sshserver.yourdomain.com and YOURDOMAIN.COM with the appropriate values). Create the principal using the following command on the kadmin console (sudo kadmin.local on the KDC server:

kadmin.local:  addprinc -randkey host/sshserver.yourdomain.com/YOURDOMAIN.COM

In addition you have to add this principal to the keytab on your SSH server (we assume the KDC and SSH server are the same machine. Otherwise you have to scp the keytab to your SSH machine):

kadmin.local:  xst host/sshserver.yourdomain.com/YOURDOMAIN.COM

Restart your ssh service and try to login. You can watch the /var/log/auth.log file for error messages and execute ssh with some -v options for debugging problems.

Resources

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

Local System Resources

Ubuntu Wiki Resources

• OpenSSH 4.3 VPNs describes how to create a Virtual Private Network with recent versions of SSH.

• GPG & OpenSSH describes how to use GPG to sign SSH keys.

WWW Resources

Keeping SSH access secure

OpenSSH Website

Password-less logins with OpenSSH

CategorySecurity

Parent page: Internet and Networking