UbuntuHelp:AdvancedOpenSSH

文章出处:

https://help.ubuntu.com/community/AdvancedOpenSSH

点击翻译:

English  • 中文

请不要直接编辑翻译本页，本页将定期与来源同步。

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 Serve

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

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 o

ssh

rver from the repositories. Notice that a fi

ssh

nfig 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

ssh

} 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 t

sshd

rver 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 for

ssh

tacks, 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 connect

ssh

ients.

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

ssh

}, 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 Ubun

ssh

onfig, 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) v

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

sshd

a Different Listeni

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 standa

sshd

stening 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 yo

sshd

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

sshd

very trivial. Simply add one, or more Port directives to your

/etc/ssh/sshd_config

file, as such:

Port 2222

If you wished to ha

sshd

sten 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

/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. ;-)

Troubleshooting

username@host's password:

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 t

/etc/ssh/sshd_config

ntains the following lines, and that they are uncommented;

PubkeyAuthentication yes
RSAAuthentication 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!

Permission denied (publickey)

If you're sure you've correctly configured sshd_config, appended your public key to authorized_keys, and have your private key in the .ssh directory, and still getting this error:

Permission denied (publickey).

Chances are, your /home/user a

~/.ssh/authorized_keys

rmissions are too open by OpenSSH standards. You can get rid of this problem by issuing the following commands:

$ chmod go-w ~/
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys

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
~/.ssh/authorized_keys	The OpenSSH Secure Shell Daemon (sshd) configuration file
/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

---