.Pro OpenSSH phần 9 pdf

CHAPTER 9 ■ SCRIPTING WITH OPENSSH 225 echo "You have entered an invalid POST entry! <br/>"; exit; } $REMOTE_USER="scripter"; $SSH_PATH="/usr/bin/ssh"; print "$REMOTE_USER@$system:> $command<BR>\n"; print "<br/>\n"; $results=shell_exec("$SSH_PATH $system -l $REMOTE_USER \"$command\""); print "<pre>"; print nl2br($results); print "</pre>"; ?> Figure 9-2 shows the output from running the PHP example with the uptime command. Web applications that utilize SSH to perform commands and gather data are both useful and dangerous. Planning is the key to success with this type of scripting implementation. Also, remember to restrict the commands that a public key can use by using the command options. The web front end provides an easy-to-use SSH client for users on Windows systems without another client installed. Additionally, many web applications can now be run from cell phones and PDAs. This can really help out when being onsite is not an option. Summary Scripts are without a doubt my favorite thing that a proper OpenSSH architecture can provide. While OpenSSH does not have a whole lot to do with scripting, it enables so much work to be automated and repeated with consistency that otherwise would be difficult, if not impossible, to achieve. Figure 9-2. Output of a simple SSH/PHP application 4762ch09.qxd 9/16/05 12:01 PM Page 225 CHAPTER 9 ■ SCRIPTING WITH OPENSSH226 Once I started using scripts in conjunction with OpenSSH and keys, I was amazed at how much more work I could get done. I went from managing around 30 servers poorly to managing hundreds with little incident. Of course, if you are migrating from a remote shell environment, you are used to these types of luxuries, but I was normally working with Telnet and FTP, which lack the scripting capabilities provided by OpenSSH. You also might have noticed that I did not use SFTP once during the scripts in this chapter. There is certainly nothing stopping you from using SFTP in shell, bash, or on the Web, but I often find it cumbersome in comparison to SCP. I find that SFTP is nice for interactive users, but normally from a script, SCP will perform the task in fewer steps. Scripts take time to develop and tune to your setup and environment. I encourage you to try a few of the examples provided in this chapter, and then modify them to provide the functionality you need. My script directories normally have dozens of scripts in development and usage, with dozens more archived. Scripts and OpenSSH can make UNIX/Linux adminis- tration a very rewarding career. If you happen to be running an SSH product other than OpenSSH, you will see that your scripts and actions might not all be working like you had hoped. Chapter 10 covers SSH inter- operability between products and the advantages and disadvantages of another SSH option, SSH Tectia Server. 4762ch09.qxd 9/16/05 12:01 PM Page 226 227 CHAPTER 10 ■ ■ ■ SSH Tectia Server OpenSSH, while certainly the most popular SSH protocol implementation, is not the only option. Perhaps the most notable of alternatives is SSH Tectia Server, a product offered by SSH creator Tatu Ylönen’s company, SSH Communications Security (http://www.ssh.com). Over the years, this product has evolved from supporting just a few operating systems to supporting nearly every commonly used operating system including IBM AIX, Sun Solaris, HP-UX, Red Hat Linux, SUSE Linux, Microsoft Windows, and more recently, mainframe operating systems. ■Note The main product that replaces SSH Secure Shell for Servers is now called SSH Tectia Server (A). This naming convention changed when SSH Secure Shell for Servers reached the 4.0 release. The Tectia line of products is an implementation of the SSH-2 protocol. If you are familiar with OpenSSH, switching to and from the Tectia line of products is ini- tially very frustrating. After some experience with both, however, you will see that each has its own advantages and disadvantages. When discussing SSH and implementation of product options between OpenSSH and SSH Tectia Server, questions will come up as to why one should be used over another. The main focus of this chapter is not about making that choice for you, but to illustrate some examples of advantages, disadvantages, and interoperability scenarios that should help you make an informed decision. The Pros and Cons of SSH Tectia Server Before installation and interoperability are covered, it is a good idea to briefly discuss possible advantages and disadvantages of SSH Tectia Server when compared with OpenSSH. Advantages Over OpenSSH The commercial SSH Tectia product has some distinct advantages over the OpenSSH imple- mentation of the SSH protocol. Some organizations find these benefits to be great enough to justify the cost of the product, while others find that OpenSSH provides the security and connectivity required. 4762ch010.qxd 9/16/05 12:02 PM Page 227 CHAPTER 10 ■ SSH TECTIA SERVER228 Standard Microsoft Windows Client In most environments, workstations run a Microsoft Windows operating system. While OpenSSH has no official client for Windows, SSH Communications Security does. Their client offers pro- file saving, key caching, and a really nice feature that allows opening a file transfer session via SFTP to a machine you are already connected to. ■Note SSH connectivity clients, including the SSH Tectia Client, are covered in Appendix A. This client does not provide an X server for X11 applications. To use X applications, you will need a third-party X server such as Cygwin (http://www.cygwin.com), Hummingbird Exceed (http://www.hummingbird.com), X-Win32 (http://www.starnet.com), or AttachmateWRQ Reflection (http://www.wrq.com/products/reflection/win/). Authentication Options SSH Tectia Server allows for some authentication methods different from those provided by the stock OpenSSH implementation. The Tectia line supports, in total, Public Key Infrastruc- ture (PKI), RSA Security’s SecurID, Kerberos, GSSAPI, public key authentication, PAM, password authentication, and keyboard-interactive methods. Most often, public key authentication, PAM, and passwords are used, but the other options do provide a strong authentication if your organization has those needs. Typically, RSA Security’s SecurID technology is used on perimeter firewalls, VPNs, and for access to highly sensitive systems. PKI requires certificates for users and systems, thus requiring a large infrastructure support and maintenance commitment. Working with some of the unique authentication options presented by SSH Tectia Server can be challenging. Luckily, SSH Communications also provides technical resources, in the form of web documentation, knowledge banks, and con- sultants, to help your organization meet these challenges. Management Options SSH Communications Security has a product called the SSH Tectia Manager, which can manage their SSH software. This web-based application uses encrypted communication to distribute, start, stop, and upgrade SSH Tectia products on remote targets. It also populates all host keys from managed hosts into each host, eliminating the need for end users to do so. The SSH Tectia Manager can also generate and store SSH server and client configuration files and distribute them to managed end points. The Manager provides a log file of which sys- tems got the updated configuration files and which ones it failed on. License management is also handled by the Manager so an administrator can know how many licenses he or she has in use. The SSH Communications Security SSH Tectia Manager makes managing SSH easier for less technically oriented support staff, but it comes with a hefty price tag. 1 1. At the time of writing, the SSH Tectia Manager product is not available for direct purchase from http://www.ssh.com. Purchase agreements must be reached with the company. 4762ch010.qxd 9/16/05 12:02 PM Page 228 CHAPTER 10 ■ SSH TECTIA SERVER 229 SSH Tectia Server Disadvantages Picking the right tool for the right job is critical, and even more so when dealing with informa- tion security. Nearly all the knowledge in this book applies to both OpenSSH and commercial products, but because the market is most heavily saturated with OpenSSH, that was the focus for the majority of the book. The Tectia product line can be tuned and made to run better than OpenSSH in some situations, or it can crumble with the wrong type of administration. Just as the Tectia product has advantages over OpenSSH, it also is missing some items of importance compared to OpenSSH. Package Dependencies The most frustrating thing I run into when using SSH Tectia Server is the package dependency issues on Linux. Oftentimes, packaging/patching tools (even simple ones such as apt/yum) will not allow a system to be patched without meeting every dependency for every package already installed on the system. These options can be overridden, but not meeting dependencies can cause stability issues. Having to remove packages in the middle of the RPM dependency stack is challenging, and working with holes in that stack can be very difficult over time. Additionally, when working with support personnel from third-party vendors such as IBM, HP, SUN, and Novell, they normally expect OpenSSH to be installed on the machine. Their documentation will all be geared toward OpenSSH, and you will have to translate it for the sup- port staff and your organization. Sometimes support personnel will even ask you to remove the SSH Tectia Server product and place OpenSSH on the system to prove the problem is not stemming from sshd2. The dependency issue seems to show itself much less on other flavors of UNIX that do not build upon OpenSSH being installed. Certain clustering software products also have configuration and support documentation geared to OpenSSH. While they can almost always work with SSH Tectia Server, documentation must be adjusted. Privilege Separation The sshd2 daemon runs as root, no matter who you connect to the machine as. Although I have not seen an exploit for this, it makes me uncomfortable. Using OpenSSH with privilege sepa- ration causes the sshd daemon to spawn a new sshd running with user stahnke’s privileges and not with root privileges after successful authentication. Before authentication, OpenSSH uses a restricted environment running as the sshd user (by default) to control privilege. stahnke@www: ~> ps -ef | grep ssh root 2039 1 0 Mar07 ? 00:00:00 /usr/sbin/sshd root 31161 2039 0 14:37 ? 00:00:00 sshd: stahnke [priv] stahnke 31164 31161 0 14:37 ? 00:00:00 sshd: stahnke@pts/0 Under the Tectia product, a normal user account connects to an sshd2 daemon that runs as root all the time. This output is using the same scenario, my unprivileged account (stahnke) connected to the machine via the SSH protocol: stahnke@rack: ~> ps -ef | grep ssh root 30902 1 0 14:41 ? 00:00:00 /usr/local/sbin/sshd2 root 30909 30902 1 14:41 ? 00:00:00 /usr/local/sbin/sshd2 4762ch010.qxd 9/16/05 12:02 PM Page 229 CHAPTER 10 ■ SSH TECTIA SERVER230 Cost At the time of writing, a license of SSH Tectia Server has a list price of $774.00. This is obviously quite expensive for the home user, but for the enterprise customer, this may not be seen as an unbearable cost. This cost also does not include support and maintenance. Those agreements are reached separately with SSH Communications Security. When it comes to total cost of ownership (TCO), neither SSH implementation is free. Each requires a learning investment and time devoted to architecture, key management, patching, and technical understanding. While it may seem that saving on licensing costs is simply a ben- efit for OpenSSH, there is more to it than that. In my experience, OpenSSH is more difficult to configure, explore, and tweak for the exact parameters you require. The Tectia product offers a full range of support options from web-based to 24×7 phone support. In every SSH implementation I have done, this decision has been the hardest to make. Some companies have policies against open source tools. Some require that commercial sup- port must be available. Others are only concerned about dollars spent, not time—training costs, long-term cost, and such. Recommendations I used to recommend the Tectia solution to companies with less technical staff because they could rely on support from SSH Communications Security. However, my more recent imple- mentations have led me to rethink that stance. So much software is documented for, and tested on, OpenSSH, that it still takes a very technical understanding of SSH to make SSH Tectia solutions viable in large environments. Remember to weigh support costs versus documentation available when making a decision about which implementation of SSH to choose. In general, if you have a more technically ori- ented staff, OpenSSH will work out very nicely for you. The Tectia line provides some extremely nice management functionality and is very easy to use in most cases, but comes at a higher monetary price and will require some integration to work with third-party tools that rely on SSH. I have been working with SSH Tectia Server in conjunction with OpenSSH for the past three years at several different levels. As a personal recommendation, if you can keep your environ- ment on one type of SSH, whether it is OpenSSH or a commercial version, the end users, security administrators, and application analysts will all benefit. Working in a hybrid environment presents many challenges including management of upgrades, differences in public key–based authentication, working with operating system support from vendors, and troubleshooting connectivity problems. Installing SSH Tectia Server Obtaining SSH Tectia Server can be done by following the download link from http://www.ssh.com. Trial versions are available if you register with the company and validate your e-mail address. Commercial purchases are available online or through a company representative. The installation files come in binary format for the target operating system. Source files are included when purchasing SSH Tectia; however, if you build your own version, then you may be on your own for support also. 4762ch010.qxd 9/16/05 12:02 PM Page 230 CHAPTER 10 ■ SSH TECTIA SERVER 231 Because the SSH Tectia Server packages are provided in native operating system format, installation is done via the system package manager (rpm, pkg, depot, bff, etc.). Removing existing OpenSSH installations is recommended because it may confuse you, your users, and possibly some scripts if $PATH is set to search the directories with SSH binaries in an order that is not expected. Removing OpenSSH from a Red Hat or SUSE Linux system will cause other packages to have broken dependencies, which can lead to other problems. Some of the more important packages that rely on OpenSSH in Linux are netdump (http://www.netdump.org), which allows a kernel panic to dump memory to a remote file system; and some kdebase packages, which allows for the popular KDE (http://www.kde.org) desktop to be installed. Both of these packages will work if you are comfortable with not checking dependencies for these RPMs for installations. However, future upgrades of those packages and additional packages that depend on those packages can be a difficult experience. Other operating systems fare better than Linux does when installing the Tectia product because they normally do not ship with OpenSSH installed. The first notable difference is the requirement for a license file. This can be bothersome because the administrator must either write an installation script around the package provided by SSH Communications Security or have the installation complete, have startup of sshd2 fail, drop in the license file, and then restart the sshd2 daemon. Normally, the /etc/ssh2/ directory can be made and have the license_ssh2.dat file placed in it before installing the package, and everything will work as desired. ■Caution When upgrading versions for SSH Tectia, be especially careful to place the latest license file that came with the new package in the /etc/ssh2 directory before installing the new package. Administrators can easily drop SSH connectivity if the license file does not match the version now installed. Starting the sshd2 daemon is not possible without the proper license. The host keys are stored in /etc/ssh2. During installation, a key is generated that is, by default, 2048 bits in length. The generation of this key can take a very long time (up to one hour) on some systems. The Tectia product also installs a certd daemon, which enables the usage of PKI. Using PKI is something that the Tectia product does natively, whereas OpenSSH requires patching outside of the official OpenSSH tree to support it (http://roumenpetrov.info/openssh/). If your organization has a significant investment in PKI technology, then the Tectia product line will probably integrate into that infrastructure easier. Differences Between OpenSSH and SSH Tectia Server An initial look at SSH Tectia Server shows the Tectia file layout is quite similar to that found in OpenSSH. By default, installation of the binary files occurs in the /usr/local space. The configu- ration files are in /etc/ssh2. The commands to do almost everything the same as with OpenSSH, except each command now ends in the number 2. If OpenSSH is not installed on the system, links will be created so the applications can be named the same thing. For example, in OpenSSH, ssh is the client program. In SSH Tectia Server, it is ssh2. However, upon installation, SSH Tectia Server will link ssh to ssh2 if ssh does not already exist. 4762ch010.qxd 9/16/05 12:02 PM Page 231 CHAPTER 10 ■ SSH TECTIA SERVER232 The entropy (randomness used to generate encryption keys) for SSH Tectia is provided by /etc/ssh2/random_seed. This seed file changes a few times an hour to cause variance in the random generation algorithms used for encryption. Also provided by a default is a file called /etc/ssh2/ssh_dummy_shell.out. The ssh-dummy-shell is a shell that the Tectia product can use to provide only SCP/SFTP capabilities to a user. The contents of /etc/ssh2/ssh_dummy_shell.out are given to any user having the dummy shell as their shell and attempting an interactive ssh2 connection. This is the output when using the dummy shell for an attempted ssh2 client connection: stahnke@rack: ~> cat /etc/passwd | grep dummy dummy:x:503:503::/home/dummy:/usr/local/bin/ssh-dummy-shell stahnke@rack: ~> ssh dummy@rack dummy's password: Authentication successful. This is ssh-dummy-shell. Edit /etc/ssh2/ssh_dummy_shell.out in order to alter this message. Press any key to exit. Connection to rack closed. ■Caution The output file is called ssh_dummy_shell.out with underscores, but the shell itself is called ssh-dummy-shell, with hyphens. This can be quite confusing. Public Key Authentication with SSH Tectia Server Public key authentication is set up a little differently than in OpenSSH. First off, the user’s home directory for SSH information is $HOME/.ssh2 rather than .ssh. Additionally, the private key file (1024-bit DSA) is normally called id_dsa_1024_a, and the public key is called id_dsa_1024_a.pub. RSA keys are also supported in the SSH Tectia product line. The local side should have a file called $HOME/.ssh2/identification, which lists each private key the account will be using, one per line. Each line starts with idkey as the token. stahnke@rack: ~> cat $HOME/.ssh2/identification idkey id_dsa_1024_a On the remote machine side, the public key needs to be placed in the remote user’s .ssh2 directory. Additionally, a file called authorization must exist with the following syntax. This example shows that multiple keys are allowed: stahnke@rack: ~> cat $HOME/.ssh2/authorization key id_dsa_1024_a.pub key id_rsa_2048_a.pub For public key authentication to work properly, the file pointed at by the authorization file must exist and have secure permissions (not world accessible). Using separate files for these tasks may seem inconvenient at first, but from a key management prospective, it is much easier. If I want to revoke a key, rather than rebuild an authorized_keys file, the public 4762ch010.qxd 9/16/05 12:02 PM Page 232 CHAPTER 10 ■ SSH TECTIA SERVER 233 key file can simply be removed from the remote systems, thus leaving all other keys still intact. This does assume that not all keys are named the same thing. During my SSH implementations involving the SSH Tectia Server product, I normally rec- ommend a username.source_node naming convention for a public key. This is nice because in the logs, sshd2 reports which public key is used to gain access. This eliminates having to trace key fingerprints if the multiple keys are authorized for an account. stahnke@rack: ~> ssh root@rack root@rack: ~> cat /var/log/secure Mar 13 13:55:39 rack sshd2[29450]: connection from "192.168.1.101" (listen iface: *** SSH_IPADDR_ANY ***:22) Mar 13 13:55:39 rack sshd2[30442]: User authorized by public key: "1024-bit dsa, stahnke@rack, Sun Mar 13 2005 13:54:03 -0600", fingerprint: xorid-gisyd-tufan-posiz-sisyb-cubym-ledyv-pepyp-zatup- nipec-laxox Mar 13 13:55:39 rack sshd2[30442]: Public key /root/.ssh2/stahnke.rack authorized for user root, verifying signature. Mar 13 13:55:39 rack sshd2[30442]: Public key authentication for user root accepted. Mar 13 13:55:39 rack sshd2[30442]: ROOT LOGIN: User root (uid 0), coming from rack, authenticated. From the logs, I can see that stahnke.rack was used to authenticate. If I am confident in the naming convention, then I can be fairly sure this was the user stahnke coming from the host named rack. Configuration of SSH Tectia Server Configuration files for SSH Tectia are stored in /etc/ssh2. These work in the same manner as with OpenSSH. The files are called sshd2_config and ssh2_config for the server and client, respectively. The sshd2_config is a well-documented configuration file, and the man pages will also assist you in developing a configuration file. ■Tip The per-user client configuration is called $HOME/.ssh2/ssh2_config and not just config as with OpenSSH. The Tectia Server allows an administrator to tailor the configuration on a per-user and per-host basis. This is bit more granular than OpenSSH. The usage of subconfiguration files, or subconfigs, is supported in sshd2. A subconfig can specify that, from a certain host, this configuration for sshd2 applies, whereas normally it would rely on the system defaults. SSH Communications provides a few examples for every configuration file they use, which can be a nice baseline for configuration. Their subconfigs provide examples for user-based configurations, host-based configurations, and anonymous examples. 4762ch010.qxd 9/16/05 12:02 PM Page 233 CHAPTER 10 ■ SSH TECTIA SERVER234 ■Note The SSH Tectia Server anonymous example for SFTP is not the same as an anonymous FTP site. To use the SFTP anonymous account, a password must be known by all users of the account. With traditional FTP anonymous access, any valid e-mail address can act as a password. This makes anonymous SFTP more like a shared-password account than a true anonymous access account. SSH Tectia Server gives system administrators the ability to contain users to specific directo- ries that appear to end users, to be at the root (/) level. This prevents users from accessing critical system files or seeing the entire directory structure. This is called jailing or change-rooting (chrooting) a user. The chrooting options inside of SSH Tectia Server are very nice to use. SSH Tectia Server provides options inside of the sshd2_config file that allow specific users and mem- bers of specific groups to be chrooted. Additionally, when using the ssh-dummy-shell, the account is only usable for file transfers and not for interactive shell access. This is ideal for users who only update website content or transfer data from one system to another. The configuration options are documented in the man pages and the support area of the SSH site (http://www.ssh.com/support). Most of the tokens enable similar functionality or restrictions as compared to the options found in OpenSSH. Configuration Differences If you are attempting to maintain pristine configuration files for both of your SSH versions, remember that SSH Tectia uses /etc/ssh2/sshd2_config and OpenSSH uses /etc/ssh/sshd_config. Many administrators forget and might accidentally overwrite a good configuration file with one from a different SSH implementation, which will break the daemon until the configuration file is fixed. ■Tip Remember to use sshd -t to verify OpenSSH configuration before starting sshd with the new configuration. The tokens in the configuration files also have differences. For example, PermitRootLogin in OpenSSH has yes, no, and without-password. In SSH Tectia, it is yes, no, and nopwd, which carries the same meaning. If you work with both distributions enough, you will find yourself wishing that OpenSSH had some features of the SSH Communications Security product and vice versa. Patching SSH Tectia Server SSH Tectia does not rely on OpenSSL for product functionality. This can be a good thing because if a vulnerability is found in OpenSSL, the SSH Tectia Server is not affected because the Tectia line of products provides their own encryption libraries. However, because SSH Tectia Server is bundled with its own encryption libraries, vulnerabilities may be found in those that do not affect the open source products. Purchasing SSH Tectia Server for strictly security reasons is probably not a good justification for the purchase. Any software will require patches and updates. 4762ch010.qxd 9/16/05 12:02 PM Page 234 [...]... MIIBvAIBAAKBgQCsTv3n7Ry6/30YnwE/hDZLsIxBB5pWtDLDukuS53OqEXcP8vOQ r30OZDJjLYzjsZr/9PpRneGrweHRgUGd+n8QDu2wvYPRcKYYJJukK/2S82FUHxCH JrVFM6JbnrVZnfxK8zKML0UbjrwwlfZnVEkyU6Eov3/vF5w2MDdN/BnKuwIVAJ1Y XHFpsx3q+y2pMTKi5C9/BS7NAoGBAKWPd+wVYSG5onkdh5L4QDF89vPto3y5XFQR 580o2/Fi87RedXRtK6cS1Oted8qTOrVNMHuZCL/fBIAP28uCJplCXi7rkrDA85X4 qzXiX32KI6En9gzOUhCull8zdCiSFLFnizkKSSAX3oKp7ypT+mql38MrY99q4hIu vIcqwW84AoGBAKZKn081ZiDyKOjwyqFGiKAXH2HSJmRup6I7VE0Lhjb6LxQbKrEi... generated using OpenSSH, at least natively Working with keys from OpenSSH to Tectia is challenging, but luckily OpenSSH includes some utilities to help manage the differences between the SSH implementations The ssh-keygen utility provided with OpenSSH allows private and public keys from SSH Communications Security, which are in the IETF SecSH format, to be imported and exported to and from OpenSSH In my... might consider changing For instance, sometimes it is necessary to scroll back through many session lines for debugging purposes To lengthen the history, enable 99 99 lines of scrollback capabilities, as shown in Figure A-2 4762chAppA.qxd 9/ 16/05 12:07 PM Page 243 APPENDIX A ■ SSH CLIENT ALTERNATIVES Figure A-2 Configuring PuTTY with a larger scrollback buffer Also, it is quite convenient to be able... however, will require some modification 235 4762ch010.qxd 236 9/ 16/05 12:02 PM Page 236 CHAPTER 10 ■ SSH TECTIA SERVER ■ If you find yourself needing to use scp from an OpenSSH client to a Tectia Server, you can install the Tip OpenSSH version of scp as /usr/local/bin/scp1 This will allow the SSH Tectia Server to accept scp connections from OpenSSH clients scp1 must be in the same directory as the ssh/ssh2... qzXiX32KI6En9gzOUhCull8zdCiSFLFnizkKSSAX3oKp7ypT+mql38MrY99q4hIu vIcqwW84AoGBAKZKn081ZiDyKOjwyqFGiKAXH2HSJmRup6I7VE0Lhjb6LxQbKrEi d676xHjeeDOknJ7BAjZoFgzMoMmcX9UjupCwo7TIEcjRh5L8acSBRmoyjx77Enev U6YKw+XXiZZPBt1N6tY/XCyMPjyvJ5T2djqqlo4ytAgqDkfDKo62JD7JAhQjGp 89 9bR0rpyXr/TGLucI57P7hg== -END DSA PRIVATE KEY Importing private keys from SSH Tectia to OpenSSH is not usually practical because most private keys (I would hope all of them) have passphrases You... public keys from Tectia and put them in OpenSSH format From there, just append the output to an authorized_keys file, and authentication should work as it normally does using OpenSSH This code uses ssh-keygen to import commercial public keys and append that key to an OpenSSH authorized_keys file This authorized_keys file can now be placed on a system running OpenSSH and allow clients using SSH Tectia... to authenticate 4762ch010.qxd 9/ 16/05 12:02 PM Page 237 CHAPTER 10 ■ SSH TECTIA SERVER stahnke@www: ~> ssh-keygen -i -f commercial_public_key >> \ authorized_keys stahnke@www: ~> cat authorized_keys ssh-dss AAAAB3NzaC1kc3MAAACBAKxO/eftHLr/XRifAT+ENkuwjEEHmla0MsO6S5Lnc6oRdw/ y85CvfQ5kMmMtjOOxmv/0+lGd4avCEdGBQZ36fxAO7bC9g9Fwphgkm6Qr/ZLzY5QfEI cmtUUzoluetVmd/ErzMowvRRuOvDCV9mdUSTJToSi/f+8XnDYwN038Gcq7ABAAFQCdW... have the OpenSSH- provided ssh-keygen on the system where you run this script The script expects ssh-keygen to be in $BASE_DIR This rpm generation script, presented in Listing 10-1, will convert all keys dropped in $BASE_DIR/ssh2 to OpenSSH format and make an rpm that has both commercial and OpenSSH public keys in their respective directories Listing 10-1 A Script That Creates an RPM with Both OpenSSH. .. and is # only accessible to system administrators 237 4762ch010.qxd 238 9/ 16/05 12:02 PM Page 238 CHAPTER 10 ■ SSH TECTIA SERVER # ssh2 is for Tectia # ssh is for OpenSSH # $BASE_DIR/ssh-keygen is the ssh-keygen provided with OpenSSH #Ensure we start in the correct directory cd $BASE_DIR #Remove old RPM if it is there rm -f *rpm #If OpenSSH directory does not exist, create it if [ ! -d $BASE_DIR/ssh ]...4762ch010.qxd 9/ 16/05 12:02 PM Page 235 CHAPTER 10 ■ SSH TECTIA SERVER For a number of years, OpenSSH was on SANS.org’s The Twenty Most Critical Internet Security Vulnerabilities (http://www.sans.org/top20) This led to OpenSSH getting a bad reputation for needing to be patched several times a year for critical security flaws The number of security flaws found in OpenSSH has dramatically . achieve. Figure 9- 2. Output of a simple SSH/PHP application 4762ch 09. qxd 9/ 16/05 12:01 PM Page 225 CHAPTER 9 ■ SCRIPTING WITH OPENSSH2 26 Once I started using scripts in conjunction with OpenSSH and. the SSH protocol: stahnke@rack: ~> ps -ef | grep ssh root 3 090 2 1 0 14:41 ? 00:00:00 /usr/local/sbin/sshd2 root 3 090 9 3 090 2 1 14:41 ? 00:00:00 /usr/local/sbin/sshd2 4762ch010.qxd 9/ 16/05 12:02. Server product and place OpenSSH on the system to prove the problem is not stemming from sshd2. The dependency issue seems to show itself much less on other flavors of UNIX that do not build upon OpenSSH