Tài liệu 7 Things Every System Administrator Should Know About OpenSSH pptx

The Basics The most essential thing to know about OpenSSH is how to use the OpenSSH client, simply called ssh, to con-nect to an SSH server.. Note that the server does not have to be th

7 Things Every System Administrator

Should Know About OpenSSH

Expert Reference Series of White Papers

OpenSSH is an open-source implementation of the SSH (Secure SHell) protocols, originally developed in 1995

by Tatu Ylönen SSH-based tools provide secure client/server connections and are usually designed to replace

older remote-access tools like rsh and telnet Unlike their predecessors, SSH-based tools encrypt their

trans-missions, making it difficult or impossible for intruders to “sniff” important information, such as passwords, from the data stream SSH implementations exist for every major platform including Microsoft Windows This paper will focus on the OpenSSH implementation, which was initially developed as part of the OpenBSD proj-ect and is installed by default on most modern BSD and Linux-based operating systems, including Red Hat Enterprise Linux and Fedora The goal of this paper is to provide a brief introduction to several techniques for

getting the most out of this powerful tool More information on most of these topics can be had from the ssh

and related man pages, as well as the openssh website, http://www.openssh.org

The Basics

The most essential thing to know about OpenSSH is how to use the OpenSSH client, simply called ssh, to

con-nect to an SSH server Note that the server does not have to be the one provided by OpenSSH Any server that supports the SSH protocols may be used Below is an example of a simple ssh connection from a system called

satsuki to a system called mei

[brad@satsuki ~]$ ssh mei

The authenticity of host 'mei (192.168.5.7)' can't be

estab-lished.

RSA key fingerprint is

b2:8d:aa:5a:32:f8:21:79:25:c1:cd:3b:a9:4c:d4:7d.

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added 'mei' (RSA) to the list of known

hosts.

brad@mei's password:

Last login: Sat Jul 28 11:29:40 2007 from satsuki

[brad@mei ~]$

There are two important things to note about this First, upon connecting to a host for the first time, you are prompted to record its host key This is a unique value that will be used the next time you connect to a system

called mei to verify that it is the same system whose key you recorded previously This prevents hostile

sys-tems from recording passwords by hijacking the IP address or hostname of an SSH server and impersonating it

Brad Smith, Red Hat Instructor, RHCE

7 Things Every System Administrator Should Know About OpenSSH

as on the client system, brad in this case, is assumed A different username could be passed with a command like: ssh username@host.

Key-Based Authentication

Many remote access tools, including predecessors of ssh like rsh, provide mechanisms for allowing

password-less access to a system Password-password-less access is a very useful thing to have as it allows for a much higher level

of automation than can be achieved when a password must be provided for every connection The problem with such mechanisms was that they tended to be insecure After all, if connections do not require a password, what assurance can you have that the person connecting to your service is actually authorized?

Openssh deals with this using a system very similar to the host key mechanism discussed earlier Two mathe-matically related keys, called a public key and private key are generated to identify a user The public key is copied to an SSH server, allowing it to use the mathematical relationship between the public key it holds and the private key held by the client to only authenticate clients that hold the appropriate private key The end result: password-less authentication that is secure so long as the private key is kept private

Configuring key-based authentication requires two steps:

1 Create a keypair by running ssh-keygen -t rsa The keys will be stored in ~/.ssh/id_rsa and

~/.ssh/id_rsa.pub

2 Copy your public key to a file on the SSH server called ~/.ssh/authorized_keys, with permissions 600 On

most modern Linux distributions this can be done easily with the copy-id command, e.g.,

ssh-copy-id mei

One problem with this arrangement is that if anyone compromises your account, they can use the private key stored there to access any server that uses it For this reason, you will be given the option during key-creation

to assign a password to the key If a password is assigned, it must be provided before the key can be used

“But wait,” you say, “what's the point of key-based authentication if you're just going to use a password any-way?” First, the key-password adds a second layer of authentication, further strengthening your security

Second, if you are using the Gnome desktop environment, you can run the ssh-add utility to enter your

pass-word once and then not worry about it for the rest of your login session Outside of Gnome, you need to use

ssh-agent, more information about which can be learned from its man page.

Remote Execution

The OpenSSH client can be used for more than just remotely accessing a command prompt If a command is passed as an argument to the client it will connect and then, instead of providing a shell prompt, run the

com-mand, display its output, and disconnect For example, the following command would connect to mei, run the

w command to display all logged-in users and then disconnect:

[brad@satsuki ~]$ ssh mei w

18:52:49 up 47 min, 2 users, load average: 0.10, 0.11, 0.14

0.07s bash

[brad@satsuki ~]$

Imagine this combined with key-based authentication (note that the example above does not prompt for a password) to non-interactively perform tasks or gather data on each SSH server on your network and you will see why this can be an indispensable administrative tool

Piping over SSH

Building on the previous topic, OpenSSH can also be used to transmit the output of a program on one system

to the input of a program on a remote system via the pipe operator, '|' This works just like a normal pipe, but the data is sent from one system to the other over OpenSSH's encrypted connection The following is a simple

example of sending the output of the afore-mentioned w command on satsuki directly to a file on mei This takes advantage of a little-known feature of the cat command, which allows it to send whatever it receives on

its standard input directly to its standard output, which can in turn be redirected to a file Note that we also

show off a bit by using bash's command-interpolation feature to embed a datestamp into the file's name:

[brad@satsuki ~]$ w | ssh mei 'cat > satsuki-logins-$(date

+%Y%m%d).txt'

[brad@satsuki ~]$

For a more advanced but arguably cooler example of piping over SSH, consider the following, which uses the

dd command to store a byte-for-byte image of satsuki's /dev/hda1 partition in a file called hda1.img on mei.

[brad@satsuki ~]$ dd if=/dev/hda1 | ssh mei 'dd of=hda1.img'

[brad@satsuki ~]$

File Transfers Over SSH

So far, we have looked at OpenSSH as a remote access and remote execution tool to replace older utilities like

rsh and telnet However, OpenSSH may also be used as a file transfer utility to replace, for example, ftp This

capability is presented in the form of two utilities that are usually included with the OpenSSH package: scp and sftp The sftp utility functions just like an FTP client, implementing the familiar cd, ls, get and put

com-mands, but establishes a secure connection to an SSH server instead an insecure connection to an FTP server

The scp utility is modeled after the older rcp utility and follows essentially the same syntax as the basic cp command, that is: scp source destination Either the source or destination can describe a foreign file using the format user@host:/path/to/file As with normal ssh, if no username is given, your current name will be

used To illustrate, the following command recursively copies the /etc/sysconfig/network-scripts/ directory from

mei to satsuki:

[brad@satsuki ~]$ scp -r mei:/etc/sysconfig/network-scripts

brad@mei's password:

output truncated

There are also graphical tools, such as gftp and Gnome's default file manager, nautilus, which employ the

SSH protocol for simple drag-and-drop secure file transfers

Tunneling Other Protocols Over SSH

Unfortunately, OpenSSH cannot be used to replace every insecure protocol, but many of those it cannot replace, it can enhance by tunneling them over a secure connection This is done with a technique called port

forwarding Port forwarding is enabled by using the -L option when establishing a connection to an SSH server.

-L should be followed by a local port, a destination hostname and a destination port separated by colons.

Upon establishing a connection, the OpenSSH client binds to your loopback interface (127.0.0.1) and begins listening on the local port Any traffic sent to that port is forwarded over the encrypted connection to the SSH server, which then forwards the traffic, to the destination host and port So even though the traffic in question

is sent unencrypted by the client and received unencrypted by the server, it is protected during its trip from your system to the SSH server This can be done for any TCP-based service, but not services that use other transport protocols like UDP

A common practical example of OpenSSH is securing a VNC connection VNC is a very handy, cross-platform, graphical remote access tool However, most VNC clients do not support encryption, making everything you do

visible to snoopers OpenSSH to the rescue! Assume that there is a VNC server listening on port 5901 of mei

and consider the following command:

[brad@satsuki ~]$ ssh -L 25901:mei:5901 mei

Last login: Sat Jul 28 23:05:49 2007 from satsuki

[brad@mei ~]$

Once this connection is established, a VNC client may be run on satsuki, pointed at localhost:25901 The

client's traffic would then be forwarded from the listening OpenSSH client across the SSH connection to the

server, from which traffic would be forwarded to the VNC server on port 5901 of mei:

Because the machine we are connecting to with OpenSSH and the machine hosting the destination VNC server

are one and the same, traffic would only be visible in its unencrypted state to users with root access to

satsu-ki or mei.

Related to this is OpenSSH's ability to tunnel X.org-compatible graphical applications, which includes just about every graphical application in most Linux distributions Setup for this type of tunneling is especially easy:

just connect to a host using the -X option and type the name of a graphical application The application

should then appear on your screen, tunneled over OpenSSH's encrypted connection

It is important to note that with these powerful techniques come some security concerns Consider that the above example would work even if your firewall was configured not to allow remote users to use VNC, or that

by specifying a destination host other than mei, the SSH server could be used to establish tunnels into other internal systems These tunnels could even be shared from satsuki by making the forwarding client listen on a

public interface instead of the loopback, which could completely negate your firewall This risk can be

mitigat-ed somewhat (though the flexibility of OpenSSH means you are taking some risk just by giving users the ability

to connect) by only allowing port forwarding for certain users, as demonstrated by the following snippet from the OpenSSH server's configuration file, which is /etc/ssh/sshd_config on Red Hat Enterprise Linux and Fedora:

AllowTcpForwarding no

X11Forwarding no

Match Group sshforwarders

X11Forwarding yes AllowTcpForwarding yes

Important Server Configuration Options

In most Linux distributions, OpenSSH keeps its server configuration options in /etc/ssh/sshd_config While a thorough discussion of all of the options that can be set here is outside the scope of this paper, I will list some

of the most important:

AllowRoot: Set to “yes” or “no”, this setting determines whether or not the administrative user may connect to the server While this may limit what administrative tasks can be accomplished

non-interactive-ly via SSH, the prevalence of attacks that simpnon-interactive-ly try to guess an SSH-capable system's root password make it advisable to turn this feature off

AllowUsers: When set to a space-delimited list of users, only those users may connect to the

serv-er Users may be specified with the format user@hostname, to further limit them by the host that they are

con-necting from For example, brad@satsuki would only allow the user brad to connect from the host satsuki.

AllowGroups: When set to a space-delimited list of groups, only members of the specified groups may connect to the server It is extremely important to remember that if both AllowGroups and AllowUsers are specified, a user must both be specified by AllowUsers and a member of a group specified by AllowGroups Banner: When set to the location of a file, the content of that file is displayed to incoming clients before they are authenticated This allows your system to display a notice warning potential trespassers that this is a restricted system, which can be more important than you might think if it comes to prosecution Consult your legal department for details and appropriate wording

Protocol: When set to any combination of 1 and/or 2, this option defines which version of the SSH protocol to use The original protocol version 1 is more vulnerable to certain types of attack than its suc-cessor, so it is recommended that this be set to 2, forcing all clients to use the newer version of the protocol

Also, don't forget about AllowTcpForwarding, X11Forwarding and Match blocks as described in the tunneling

section The complete list of available configuration options can be found in the sshd_config man page.

Summary

OpenSSH provides a powerful and flexible tool for system administrators, but like any powerful tool, without a proper understanding, its potential may be wasted or, worse, it may become a liability This paper has

attempt-ed to introduce the reader to those topics most important for the proper and effective use of OpenSSH

Many other interesting features exist, which the reader is encouraged to explore independently A few sugges-tions for further study include:

• Client configuration

• Escape characters

• Connection sharing

• Remote port-forwarding

Don't forget the ssh, ssh_config, and sshd_config man pages and extended documentation at

http://www.openssh.org for more information

Learn More

earn more about how you can improve productivity, enhance efficiency, and sharpen your competitive edge Check out the following Global Knowledge courses:

RH033 Red Hat® Linux Essentials

RH133 Red Hat® Linux System Administration & Red Hat® Certified Technician (RHCT®) Lab Exam

RH253 Red Hat® Linux Networking and Security Administration

RH300 Red Hat® Linux (RHCE®) Rapid Track Certification Course & RHCE Lab Exam

RHS333 Red Hat® Enterprise Linux Security: Network Services

RHS429 SELinux Policy Administration

RHS429 SELinux Policy Administration Exam (EX429)

For more information or to register, visit www.globalknowledge.comor call 1-800-COURSESto speak with a sales representative

Our courses and enhanced, hands-on labs offer practical skills and tips that you can immediately put to use Our expert instructors draw upon their experiences to help you understand key concepts and how to apply them to your specific work situation Choose from our more than 700 courses, delivered through Classrooms, e-Learning, and On-site sessions, to meet your IT and management training needs

Through our premier partnership with Red Hat, we bring you the power of Red Hat Enterprise Linux training and certifications

About The Author

Brad Smith installed his first Linux box while in high school in the mid-90s and has been working with Linux ever since as a system administrator, developer, and instructor He has been an instructor and courseware developer with Red Hat since 2003