特殊:Badtitle/NS100:AdvancedOpenSSH

{{#ifexist: :AdvancedOpenSSH/zh | | {{#ifexist: AdvancedOpenSSH/zh | | {{#ifeq: {{#titleparts:AdvancedOpenSSH|1|-1|}} | zh | | }} }} }} {{#ifeq: {{#titleparts:AdvancedOpenSSH|1|-1|}} | zh | | }}

Parent page: Internet and Networking

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 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 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.

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.

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

LogLevel VERBOSE

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.

Authentication

LoginGraceTime 120

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.

LoginGraceTime 20

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.

X11Forwarding yes

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.

X11Forwarding no

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!

#Banner /etc/issue.net

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.

Banner /etc/issue.net

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:

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

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

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:

AllowGroups 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 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:

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

Port 22

Port 2222

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.

RSA Key-Based SSH Logins

Key-based 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 significantly more difficult to brute-force, or guess than plain passwords, provided an ample key length.

Digital keys are also of course, 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 more secure than using plain password logins.

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, password-less logins via ssh, this guide does not describe, or endorse such use as it is very insecure. If your password-less 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 password-less logins my be desirable, but again, this guide does not explain the process of creating 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 too 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:

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 it's time 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 key pair on those machines is quite simple. For example, if you'd like to begin using key-based logins as user username on a remote machine named host, and host 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 username@host

Testing the Login

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

ssh username@host

You will be prompted for the passphrase for your key:

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

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

NOTE: The examples above were just that: Examples! Substitute the user name, and machine name in the examples 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

username@host'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;

PubkeyAuthentication yes

If not, add them, or uncomment them, restart the sshd, and try logging in again. If you get the passphrase prompt now, then congratulations, you're logging in with a key!

PROBLEMS WITH THIS SECTION

You mention "following lines" but only give one line (the Pubkey Authentication one). I have followed all of your steps (on Kubuntu 6.06) so far but it still asks for my user password.

I have done some hacking, helped by a thread at http://ubuntuforums.org/showthread.php?t=30709&highlight=ssh+RSA+key+user+password

I am not hacking with understanding, this is all seat-of-my-pants and very clueless. Please edit this to clarify/improve it all!

This is what I have found:

• You need a file on the server (machine that will be logged into) that contains the public key. In your ~/.ssh folder, as a normal user, do this:

cat id_rsa.pub >> authorized_keys
chmod 600 authorized_keys

• Now in the sshd_config file, make these changes (they may not be together one after the other like they are here):

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      %h/.ssh/authorized_keys
PasswordAuthentication no

• Now, as far as I can test (from the same machine, I know - I am not able to test it remotely just yet) I can do: ssh username@hostname and it will ask me for the passphrase to the key, not my normal user password.

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 favorite 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.

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!

Additionally, you may wish to change the PermitRootLogin directive when using key-based logins, to enforce a policy disallowing password-based root logins. You can do so by changing:

PermitRootLogin yes

to

PermitRootLogin without-password

Don't be alarmed by the without-password. This does not mean a user may login as root without supplying a password, but rather, it means no one may log in as root using password authentication, meaning that logging in as root may be done with a public key only.

Resources

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

Local System Resources

man sshd	System manual page for the sshd server daemon
man sshd_config	System manual page for the /etc/ssh/sshd_config configuration file
man ssh-copy-id	System manual page for the ssh-copy-id application
man ssh-keygen	System manual page for the ssh-keygen application
/etc/ssh/sshd_config	The OpenSSH Secure Shell Daemon (sshd) configuration file

WWW Resources

Keeping SSH access secure

OpenSSH Website

Password-less logins with OpenSSH

---