UbuntuHelp:AdvancedOpenSSH
来自Ubuntu中文
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.
attachment:IconsPage/IconWarning3.png 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.
****************************************************************************
</code>
Save the file, and then create a symbolic link to the <code>/etc/issue.net</code> file using the following command:
<code>sudo ln -s /etc/issue /etc/issue.net</code>
Once you've restarted <code>sshd</code>, 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 <code>/etc/issue</code>, 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 <code>/etc/issue.net</code> ''file'' rather than making a symbolic link from <code>/etc/issue</code>. With no text in <code>/etc/issue</code>, 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 <code>/etc/ssh/sshd_config</code> file to allow, or deny login with <code>ssh</code> 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 <code>ssh</code>, you could use the <code>AllowUsers</code> directive in your <code>/etc/ssh/sshd_config</code> file as such:
||'''<code>AllowUsers jhendrix svaughan</code>'''||
If you didn't mind all users logging in via <code>ssh</code>, with the exception of the users '''wgates''', or '''sballmer''' then you could add the <code>DenyUsers</code> directive to your <code>/etc/ssh/sshd_config</code> in a similar manner, like this:
||'''<code>DenyUsers wgates sballmer</code>'''||
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 <code>ssh</code>. In this example, we'll perform all the steps required to allow <code>ssh</code> logins only to users who are members of the group ''sshlogin''.
<code>sudo addgroup --gid 450 sshlogin</code>
<code>sudo adduser <username> sshlogin</code>
Replace '<username>' in the example above with the actual username you wish to add to the ''sshlogin'' system group. Finally, edit your <code>/etc/ssh/sshd_config</code>, and add an <code>AllowGroups</code> directive as such:
||'''<code>AllowGroups sshlogin</code>'''||
Restart <code>sshd</code>, and only users who belong to the group ''sshlogin'' will be allowed to login to your Ubuntu computer via <code>ssh</code>.
==== Start sshd on a Different Listening Port ====
In light of the recent rise in numerous automated <code>ssh</code> 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 <code>sshd</code>. 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 <code>-p</code> or <code>-P</code> switches with the various OpenSSH tools, or the modification of <code>/etc/ssh/ssh_config</code> 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 <code>Port</code> directives to your <code>/etc/ssh/sshd_config</code> file, as such:
||'''<code>Port 2222</code>'''||
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:
||'''<code>Port 22</code>'''||
||'''<code>Port 2222</code>'''||
Don't forget to save the file, and restart your <code>sshd</code> with the command:
<code>sudo /etc/init.d/ssh restart</code>
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.
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, password-less logins via <code>ssh</code>, 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 <code>ssh</code> 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:
<code>ssh-keygen -t rsa</code>
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:
<pre>
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.
</code>
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 <code>sshd</code>, and reachable by name on your network, simply use the '''ssh-copy-id''' command to properly locate your key:
<code>ssh-copy-id -i ~/.ssh/id_rsa.pub username@host</code>
==== 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:
<code>ssh username@host</code>
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.
attachment:IconsPage/IconNote.png '''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'';
||<code>PubkeyAuthentication yes</code>||
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: <pre>cat id_rsa.pub >> authorized_keys
chmod 600 authorized_keys</code>
* Now in the sshd_config file, make these changes (they may not be together one after the other like they are here): <pre>RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys
PasswordAuthentication no</code>
* 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 <code>sudo</code> and your favorite editor to edit /etc/ssh/sshd_config, and change the following directive:
||''<code>#PasswordAuthentication yes</code>''||
by uncommenting it, and changing ''yes'' to ''no'':
||'''<code>PasswordAuthentication no</code>'''||
Save the file, and restart <code>sshd</code> 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!''
Additionally, you may wish to change the <code>PermitRootLogin</code> directive when using key-based logins, to enforce a policy disallowing password-based root logins. You can do so by changing:
||''<code>PermitRootLogin yes</code>''||
to
||'''<code>PermitRootLogin without-password</code>'''||
Don't be alarmed by the <code>without-password</code>. 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 ====
||<style="background:#F1F1ED;"><code>man sshd</code>|| System manual page for the <code>sshd</code> server daemon||
||<style="background:#F1F1ED;"><code>man sshd_config</code>|| System manual page for the <code>/etc/ssh/sshd_config</code> configuration file||
||<style="background:#F1F1ED;"><code>man ssh-copy-id</code>|| System manual page for the <code>ssh-copy-id</code> application||
||<style="background:#F1F1ED;"><code>man ssh-keygen</code>|| System manual page for the <code>ssh-keygen</code> application||
||<style="background:#F1F1ED;"><code>/etc/ssh/sshd_config</code>|| The OpenSSH Secure Shell Daemon (<code>sshd</code>) configuration file||
==== WWW Resources ====
[http://www.debian-administration.org/articles/87 Keeping SSH access secure]
[http://www.openssh.org/ OpenSSH Website]
[http://www.debian-administration.org/articles/152 Password-less logins with OpenSSH]
----
CategorySecurity
[[category:UbuntuHelp]]
