“UbuntuHelp:AdvancedOpenSSH”的版本间的差异

2007年12月6日 (四) 10:03的版本

文章出处:

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

bash

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.

sshd

sshd

inetd

xinetd

/etc/ssh/sshd_config

sshd

Port 22

Protocol 2

sshd

/etc/ssh/sshd_config

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

ssh

ssh

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.

/etc/ssh/sshd_config

/etc/ssh/sshd_config

ssh

sudo /etc/init.d/ssh restart

Suggested OpenSSH Server Settings

/etc/ssh/sshd_config

Logging

LogLevel INFO

sshd

ssh

LogLevel

ssh

LogLevel VERBOSE

ssh

/var/log/auth.log

Authentication

LoginGraceTime 120

sshd

LoginGraceTime

LoginGraceTime 20

sshd

ssh

sshd

X11Forwarding yes

X11Forwarding

ssh

X11Forwarding no

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

Banner

sshd

Banner /etc/issue.net

/etc/ssh/sshd_config

sudo

/etc/issue

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

****************************************************************************

/etc/issue.net

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

ssh

/etc/issue

/etc/issue.net

/etc/issue

/etc/issue

Additional Configuration Tips

ssh

Allowed and Denied Users and Groups

/etc/ssh/sshd_config

ssh

ssh

AllowUsers

/etc/ssh/sshd_config

AllowUsers jhendrix svaughan

DenyUsers

/etc/ssh/sshd_config

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

/etc/ssh/sshd_config

AllowGroups

AllowGroups sshlogin

sshd

sshd

Port

sshd

sshd

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.

sshd

-p

-P

/etc/ssh/ssh_config

sshd

/etc/ssh/sshd_config

Port 2222

sshd

/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

ssh-copy-id

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

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:

/etc/ssh/sshd_config

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

~/.ssh/authorized_keys

$ 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!

sudo

#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!

PermitRootLogin

PermitRootLogin yes

to

PermitRootLogin without-password

without-password

Resources

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

Local System Resources

man sshd

man sshd_config

man ssh-copy-id

man ssh-keygen

ssh-keygen

WWW Resources

Keeping SSH access secure OpenSSH Website Password-less logins with OpenSSH