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

7 Things Every
System Administrator
Should Know
About OpenSSH
1-800-COURSES
www.globalknowledge.com
Expert Reference Series of White Papers
Introduction
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, .
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.
Second, note that no username w
as specified.
When no explicit username is given,
the name you are logged in
Brad Smith, Red Hat Instructor, RHCE
7 Things Every System Administrator
Should Know About OpenSSH
Copyright ©2007 Global Knowledge T
raining LLC. All rights reserved.
Page 2
a
s on the client system,
b
rad
i
n 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-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 ssh-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.
F
or 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
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
Sequoia pts/1 :0.0 18:07 41:03 0.11s
0.07s bash
Brad pts/0 satsuki 18:51 3.00s 0.03s 0.01s bash
[brad@satsuki ~]$
Copyright ©2007 Global Knowledge T
raining LLC. All rights reserved.
Page 3
I
magine 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:
ifcfg-lo 100% 254
0.3KB/s 00:00
ifcfg-eth0 100% 74 0.1KB/s 00:01
output truncated
T
here 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.
Copyright ©2007 Global Knowledge T
raining LLC. All rights reserved.
Page 4
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 forw
arded 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.
Copyright ©2007 Global Knowledge T

raining LLC. All rights reserved.
Page 5
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 simply 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.
Copyright ©2007 Global Knowledge T
raining LLC. All rights reserved.
Page 6
A
lso, 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
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 P
olicy Administration
RHS429 SELinux P
olicy Administration Exam (EX429)
For more information or to register, visit www.globalknowledge.com or call 1-800-COURSES to 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.
T

hrough 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.
Copyright ©2007 Global Knowledge T
raining LLC. All rights reserved.
Page 7