CHAPTER 9 SCRIPTING WITH OPENSSH 225
echo "You have entered an invalid POST entry!
print "$REMOTE_USER@$system:> $command
\n"; print "
$results=shell_exec("$SSH_PATH $system -l $REMOTE_USER \"$command\""); print "
print nl2br($results); print "
Figure 9-2 shows the output from running the PHP example with the uptime command.
Figure 9-2. Output of a simple SSH/PHP application
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.
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.
226 CHAPTER 9 SCRIPTING WITH OPENSSH
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.
C H A P T E R 1 0
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.
228 CHAPTER 10 SSH TECTIA SERVER
Standard Microsoft Windows Client
In most environments, workstations run aMicrosoft 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/).
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.
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.
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.
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-portstaff 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.
The sshd2daemon 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
root 31161 2039
0 Mar07 ?
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
nguon tai.lieu . vn