7 Things Every System Administrator Should Know About OpenSSH

Chia sẻ: Huy Hoang | Ngày: | Loại File: PDF | Số trang:7

Thêm vào BST

Báo xấu

76
lượt xem 30
download

7 Things Every System Administrator Should Know About OpenSSH

Mô tả tài liệu

Download Vui lòng tải xuống để xem tài liệu đầy đủ

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 transmissions, 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....

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: 7 Things Every System Administrator Should Know About OpenSSH

Expert Reference Series of White Papers 7 Things Every System Administrator Should Know About OpenSSH 1-800-COURSES www.globalknowledge.com
7 Things Every System Administrator Should Know About OpenSSH Brad Smith, Red Hat Instructor, RHCE 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, 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. Second, note that no username was specified. When no explicit username is given, the name you are logged in Copyright ©2007 Global Knowledge Training LLC. All rights reserved. Page 2
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-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. 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 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 Training LLC. All rights reserved. Page 3
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: ifcfg-lo 100% 254 0.3KB/s 00:00 ifcfg-eth0 100% 74 0.1KB/s 00:01 ... 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. Copyright ©2007 Global Knowledge Training 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 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. Copyright ©2007 Global Knowledge Training 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 Training LLC. All rights reserved. Page 6
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.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. 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. Copyright ©2007 Global Knowledge Training LLC. All rights reserved. Page 7

CÓ THỂ BẠN MUỐN DOWNLOAD