|< Day Day Up >|
Running Shells and Commands Remotely Using SSH
With the Secure Shell suite of utilities you can access your machine remotely via a shell or, if you need to transfer files, via its scp and sftp features.
What Is Secure Shell?
SSH, also known as secure shell, is a protocol for secure remote login, file transfer, and tunneling. It can be used as a secure replacement for the more familiar telnet and rlogin protocols without any noticeable difference to the user. For file transfers, SSH can be used as a secure replacement for rcp and ftp. Finally, SSH can be used to tunnel traffic over an encrypted channel. In other words, SSH can be used to transport otherwise insecure traffic more securely. For example, it can be used to encrypt the username and password data transmitted by ftp.
SSH is a more secure protocol than the traditional protocols because it encrypts traffic. The other protocols transmit data in clear text, which can then be captured by packet sniffers.
There are two versions of the SSH protocol: SSH1 and SSH2. As you might have guessed, SSH1 is the original version and SSH2 is a later development. The SSH2 protocol is the version currently being developed, although fixes are occasionally released for SSH1 because it is still in use.
The SSH protocol was first developed by Tatu Ylonen in 1995. In that same year he also founded SSH Communications Security and currently serves as its president and CEO. SSH Communications Security offers commercial and free versions of its SSH server and client products. The company originally sold products through another company called Data Fellows, which is now F-Secure. F-Secure has marketing rights for SSH and also sells SSH servers and clients. Both companies work on further developing SSH2.
There is also an SSH open source project called OpenSSH. This is the SSH distribution that Apple includes with Mac OS X. It is also based on Tatu Ylonen's early SSH code. OpenSSH provides support for both SSH1 and SSH2 protocols. There is little noticeable difference in using the SSH servers from one of the companies and from the OpenSSH package.
Because the OpenSSH package is included with Mac OS X, it is the package on which we will concentrate our discussion. Mac OS X 10.4 includes OpenSSH 3.8.1p1.
Activating the SSH Server
If you are just interested in connecting from your Mac OS X machine to another machine running an SSH server, you do not need to activate the SSH server on your machine. However, if you want to be able to access your Macintosh from a remote location, consider turning on the SSH server. To activate the SSH server, check the Remote Login box in the Services section of the Sharing pane.
Behind the scenes, this removes the disabled lines from /System/Library/LaunchDaemons/ssh.plist and loads the ssh service in launchd. The server listed in ssh.plist is a script called /usr/libexec/sshd-keygen-wrapper, which ultimately runs /usr/sbin/sshd. The file also shows that sshd is started in inetd compatibility mode. Whenever someone connects to the machine via SSH, an SSH server for that session is started. When the user logs out, the session is terminated. In early releases of Mac OS X, an SSH server ran all the time and started sshd processes for each login. With Mac OS X 10.3, Apple started running sshd out of xinetd.
Working with SSH Utilities
The SSH suite provides utilities for making terminal connections, transferring files, tunneling connections and public key authentication. In this section, we will take a look at each of the different types of SSH utilities. Table 21.1 includes a listing of the primary utilities available in OpenSSH.
Making Terminal Connections with ssh/slogin
SSH provides for secure encrypted traffic transmission across a network. Most SSH software, including that provided by Apple, includes both the encrypted transmission facility and rudimentary tools for making use of that functionality. These tools include the ability to use the encryption to provide secure terminal services and file transfer support. Other functionality can be added as needed by the user, by using just the secure transport portion of the software to encrypt the traffic between otherwise insecure external software packages.
A common use for the SSH package is for making remote terminal connections. Although you can set a number of options to ssh in a user configuration file, you will probably find yourself using ssh with command-line options initially. This is actually the easiest way to start using ssh. After you have been using ssh with command-line options for a while, you will get a feel for what options, if any, you may want to specify in either ~/.ssh/config or /etc/ssh_config.
To use the ssh client, you can either run ssh or slogin. If you are used to using rlogin on a system, slogin will be the natural choice for you. Otherwise, you probably won't have any preferences.
The most commonly used syntax for ssh is
ssh <username>@<remote_host> ssh -l <username> <remote_host>
To quickly test that sshd works on your machine, it is easiest to log in to your own machine, as shown here:
creampuf:~ nermal$ slogin 192.168.1.200 The authenticity of host '192.168.1.200 (192.168.1.200)' can't be established. RSA key fingerprint is f4:2f:a4:46:16:0c:d1:de:f2:88:d6:83:b1:26:b0:52. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.1.200' (RSA) to the list of known hosts. Password: Welcome to Darwin! creampuf:~ nermal$
Note that the first time you try an ssh action to a remote host, you are told that the remote machine's identity can't be verified, and you are asked whether it should be trusted.
After you have verified that your SSH server is running, you should be able to connect to your Mac OS X machine from another machine by using an SSH client.
Chapter 13 shows the command documentation for ssh and slogin in Table 13.4.
Transferring Files with scp, sftp
The SSH suite includes the scp (secure copy) and sftp (secure FTP) utilities for securely transferring files.
The basic syntax for scp is
scp <from> <to>
The <from> or <to> can be specified as a remote host and file, expanding the basic syntax to
scp [[<username>@]<remote_host>:]<pathtofile> [[<username>@]<remote_host>:]<pathtofile>
The <remote_host> can be a name or IP address. Here is sample output from copying a file on the remote host, ~sage/terminal/term-display-1.tiff, to the current directory on the local machine:
creampuf:~ nermal$ scp firstname.lastname@example.org:terminal/term-display-1.tiff ./ email@example.com's password: term-display-1.tiff 100% |*********************************| 900 KB 00:01
While the transfer occurs, the percentage and amount transferred increase over time. You cannot use scp to copy files from your Mac OS X machine unless you have activated the SSH server.
Chapter 13 shows the command documentation for scp in Table 13.5.
The sftp command can also be used to securely transfer files. Its basic syntax, shown following, initiates an interactive session that works much like regular ftp:
Here is sample output from an interactive sftp session:
creampuf:~ nermal$ sftp firstname.lastname@example.org Connecting to 192.168.1.17... email@example.com's password: sftp> get terminal/term-display-2.tiff Fetching /Users/sage/terminal/term-display-2.tiff to term-display-2.tiff sftp> quit
In this example, sftp is used to transfer a file on the remote host, ~sage/terminal/term-display-2.tiff, to the current directory on the local machine. As with scp, you cannot use sftp to transfer files from your Mac OS X machine unless you have activated the SSH server.
Chapter 13 shows the command documentation for sftp in Table 13.6. Only SSH2 servers include sftp.
Securing Insecure Protocols by Tunneling Connections: Command Line
As you may recall from Chapter 13, Secure Shell can be used to set up an encrypted tunnel between two machines to transfer data. Services that you might be most interested in tunneling include FTP, POP, IMAP, and X11. Note that X11 forwarding is off by default in the /etc/sshd_config file.
When tunneling a connection, you can optionally choose to restrict access to a particular service by restricting it to accept connections only from the server machine. Depending on the service, this can be done as an entry to the appropriate /etc/xinetd.d/ file or as an entry in the /etc/hosts.allow file for the server machine, 127.0.0.1. This type of setup increases the security of your machine.
To set up the tunnel, use an SSH client, such as ssh or slogin.
At the command line on a machine running an OpenSSH version of SSH, such as another Mac OS X machine, you could run the following to set up a tunnel without having a Terminal connection:
creampuf:~ nermal$ slogin 192.168.1.17 -l sageray -N -L 2121:192.168.1.17:21 firstname.lastname@example.org's password:
In the preceding statement, a tunnel is set up between the local machine and the remote host 192.168.1.17 for user sage. The remote host can be specified as a hostname or an IP address. The tunnel is created between the local host at port 2121 and the remote host at port 21. The -N option allows us to set up a tunnel without initiating a Terminal session. Please note that only root can forward ports under 1024. So, if you wanted to use a port number under 1024 on the local machine, you would have to have root privileges.
After the port forwarding is set up in the SSH client, use the regular client for the service, providing it with the appropriate local port to use and localhost or 127.0.0.1 as the host.
An FTP session over this encrypted channel would look like this:
creampuf:~ nermal$ ftp localhost 2121 Connected to localhost. 220 falcor.local FTP server (lukemftpd 1.1) ready. Name (localhost:nermal): sageray 331 Password required for sageray. Password: 230- Welcome to Darwin! 230 User sage logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> cd printing 250 CWD command successful. ftp> epsv4 off EPSV/EPRT on IPv4 off. ftp> binary 200 Type set to I. ftp> get 13FIG07.tiff local: 13FIG07.tiff remote: 13FIG07.tiff 227 Entering Passive Mode (192,168,1,17,194,93) 150 Opening BINARY mode data connection for '13FIG07.tiff' (1736394 bytes). 100% |*************************************| 1695 KB 670.55 KB/s 00:02 226 Transfer complete. 1736394 bytes received in 00:02 (669.91 KB/s) ftp> quit 221- Data traffic for this session was 3472788 bytes in 2 files. Total traffic for this session was 3501993 bytes in 7 transfers. 221 Thank you for using the FTP service on falcor.local.
Although tunneling FTP is pertinent to some of you, tunneling SMTP and a protocol such as POP may be more useful. To tunnel SMTP and POP connections over SSH, use a command such as this one:
creampuf:~ nermal$ slogin rosalyn.biosci.ohio-state.edu -l ralph -N -L 2110:rosalyn.biosci .ohio-state.edu:110 -N -L 2125:rosalyn.biosci.ohio-state.edu:25 email@example.com's password:
For the sample statement, in the POP mail client, the POP server is 127.0.0.1, and its port is 2110. For some POP mail clients, this is entered as 127.0.0.1:2110. The SMTP server is 127.0.0.1, and its port is 2125. Again, for some POP mail clients, this is entered as 127.0.0.1:2125. The 110 and 25 in the preceding statements are the ports where popper and smtp are listening on the remote host. Those are the standard ports for those services. The administrator of the remote host can tell you which ports the remote host is using. The 2110 and 2125 are port numbers we picked over 1024 so that root privileges would not be required for the tunnel. If you are using a POP mail client that does not allow you to specify an alternate port, you may have to use 110 and 25. Figure 21.1 shows the incoming mailbox of a POP account checked using our tunnel and Mail.
Figure 21.1. The incoming mailbox of a POP account checked via SSH tunnels and Mail.
In short, the basic procedure to follow for tunneling a given protocol is as follows:
A notable exception to this basic procedure is the procedure for tunneling X11 connections. The SSH server on the remote machine whose display you want to have displayed to your local machine should have X11 forwarding enabled. From your local machine, simply connect with the ssh or slogin command with the -X option, which tunnels an X11 connection. Because SSH takes care of handling everything else to make it work, you don't have to worry about details such as setting the DISPLAY environment variable. Figure 21.2 shows remotely running X11 applications being displayed to a Mac OS X machine via SSH tunneling.
Figure 21.2. X11 applications tunneled over SSH.
Securing Insecure Protocols by Tunneling Connections: Fugu
Although a number of graphical SSH clients are available for Mac OS X, so far only a few include tunneling capability. Fugu, available from http://rsug.itd.umich.edu/software/fugu/, and SSH Tunnel Manager, available from http://projects.tynsoe.org/en/stm/, are two such clients.
To tunnel a connection in Fugu, supply the following information: remote host, remote port, local port, tunnel host, username, and port. If you take another look at the example used in the in the previous section for tunneling an FTP connection, slogin 192.168.1.17 -l sageray -N -L 2121:192.168.1.17:21, the values to use in Fugu would be
If you are connecting for the first time, Fugu notes that it can verify the authenticity of the host and asks if you want to continue the connection. After you have established the tunnel, Fugu displays information about the tunnel connection. Once you've established an SSH tunnel, either via the command line or via a graphical SSH client, you can then start the application that needs to use the tunnel, as we saw earlier with Mail. Figure 21.3 setting up the tunnel in Fugu. The ability to use an FTP tunnel in a graphical application is especially useful in web editing suites that include built-in FTP clients. As web editing suites start to support SFTP, the need to use an FTP tunnel may decline.
Figure 21.3. Setting up a tunnel in Fugu.
Using Public Key Authentication
In addition to the standard method of user authentication a username and password SSH provides another method: public key authentication. With the traditional authentication method, the remote host stores a username and password pair for a user. With public key authentication, the user creates a key-pair on a given host. The key-pair consists of a private key and a public key protected with a passphrase. Then the user transfers the public key to the remote host to which she wants to connect. So, the remote host stores a set of public keys for machines on which you have generated a key-pair and transferred a copy of your public key. Furthermore, you protect your keys with a passphrase, rather than a password.
Why might you want to use public key authentication? Passwords do not provide much randomness, even if a user tries to create a password that they think can't be easily guessed. With today's technology, a machine can guess the password space in a matter of months. Passphrases, on the other hand, provide more randomness and are more difficult to guess.
The procedure for enabling public key authentication is similar for both SSH1 and SSH2. Table 21.2 provides select documentation on ssh-keygen, the utility that generates key-pairs. To enable public key authentication, do the following:
Not only are there differences in public key authentication between SSH1 and SSH2, but there are differences between SSH packages as well. The keys for SSH1 and SSH2 generated by OpenSSH differ from the ones made by SSH Communications Security's SSH servers, the other ones you are most likely to encounter. Be sure to thoroughly read the ssh-keygen, ssh, and sshd man pages for the SSH servers you have to connect to because the information you need to know for connecting via public key authentication will most likely be spread among those man pages. The keys look a bit different for the different protocols and can look quite different between the SSH packages. Fortunately, OpenSSH's ssh-keygen can import and export keys.
If you are not sure which type of SSH server a given machine is running, you can always ask its system administrator. If the system administrator is not available, you can also test this by looking at the response you get from telnetting to the machine's port 22, using the command telnet <host> 22. Here is a response from an OpenSSH machine:
dogbone:~ joray$ telnet localhost 22 Trying ::1... Connected to localhost. Escape character is '^]'. SSH-1.99-OpenSSH_3.8.1p1 ^] telnet> quit Connection closed.
Here is a sample response from an SSH Communications SSH server:
dogbone:~ joray$ telnet mother 22 Trying mother... Connected to mother. Escape character is '^]'. SSH-1.99-3.1.0 SSH Secure Shell (non-commercial) ^] telnet> quit Connection closed.
To give you an idea of how the various public keys look, some sample public keys are shown following. Default file locations were accepted when creating the keys. This first key is a sample SSH2 public key generated in OpenSSH with the DSA algorithm option (ssh-keygen -t dsa), stored as ~/.ssh/id_dsa.pub:
ssh-dss AAAAB3NzaC1kc3MAAACBALzT9RbceziStHPmMiHmg78hXUgcMP14sJZ/7MH/p2NX /fB0cmbULPNgEN8jrs8w9N73J7yUFHSPR/LVfBj+UwkIzwjyXUW/z/VmCs25IDF/UBn1OQK5 PCi16rF0F+Cx0hMN4R3AaFAetXBdLqoom5x4Yo9gdspPqhhB44QnT43JAAAAFQDWTkKDJ2m4 SApHZ/qRnRpMN5whTQAAAIAVADOsHpnUdUOFKjIgxZ0Hwh7IaMQ2ofGt/6PmbmNG/8zXRdxm u/JrBzieWHq6sSRSkWDSDIjuEuTkZyJ4wx3KsLmhIrtlBw3NCcsJT2GfGQ9gEBm8fkUpeQyK AQcirbx4Hw93iMFC3g9A8cwqmA4DalKSX3un7cweNU32Irhq+gAAAIAz+lDSjqjFzuTV4vJ/ P83nH2uwb62/iCSIB9cL32hrOm234imaAceu8pN9qqEAPr9AilCWa+lqGvgcdyDK0vZTvKQn k6KOU3TJfDyMR7i/gzW4P4TA/== miwa@brezup
This is a sample SSH2 public key generated in OpenSSH with the RSA algorithm option (ssh-keygen -t rsa), stored as ~/.ssh/id_rsa.pub:
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAnMV/YAmJdEoRFC3Fa91YVloqivKeAwD62bd4 +zSsd1lMr6JV4oE9EIfVPM3BL98UgmDzfhlh5b2PAP1YFwalXNksPeCQ0TNoBYIO1qloPwGr 00l4sllJDCgMGKphT3saumDCVryGof4g9tm3itMri/c8sA04MqOb0NS2tfBCQRc= miwa@br ezup
This is a sample SSH1 public key generated in OpenSSH with the RSA algorithm, the only choice for SSH1 (ssh-keygen -t rsa1), stored as ~/.ssh/identity.pub:
1024 35 1557212985106595841799445393895896855201842965316926480116187178 479312752731786936426534362289883814829220699448695793008292191355256581 252483513540009913562286856320477786490006280726660808370019692878286941 832867913488270433630039854375920434585040342671329990216320744276783576 66438835891174723508102956387 miwa@brezup
This key is a sample SSH2 public key generated in SSH Communications Security's SSH server with the DSA algorithm (ssh-keygen2 -t dsa), stored in ~/.ssh2/id_dsa_1024_a.pub:
---- BEGIN SSH2 PUBLIC KEY ---- Subject: miwa Comment: "1024-bit dsa, miwa@Rosalyn, Thu May 16 2002 23:33:30 -0500" AAAAB3NzaC1kc3MAAACBAIxEJgV24AtDzKyFzMAD5agu/YHOZnhUma12zVX31Ov5Xj9hU/ 0VB/FdxtctLKbUMRra5b9azzHFsdJl/f1VqoQ8feEfFZ/4nTcSVbL5f5KydmSe0Mmyq4vq IqSC4jyDjIHMUcDfj2Z/kRhF9o6VxCdCUd5OvkpZmEfWqLNR9oPlAAAAFQD02rAsEPS2uU VTAa/pHqKhcrC6mwAAAIB3UDIDjP9TOJNaap34/9o0qW1o7agFMXcJftlUgZEtUfc5v/jX MplQiL77CggJU+rdv9WQbyefaFjWLQAibV5M71kt2mdkYVtuQzbmBTDW9v8YP1/QMnnjOK v8xRmrsplC/lv9/rmzS0gI1Hfbbuq60zW/ULdg6c61y7HyZ/Qf5AAAAIArWb/PIWRhMxLR aY9VZvFZOYjOxcIR66aoybkneODPaAwZsW5yq1q2XEpxxza4q2yTyZ7drTYLCUBbXwG4Cu RVv3CMTiXQ47AXlKYPECVT0I4bTZyY60GuLI4TUsyHLk5HFF0Ctt/6OB8WEHOn6LGDNNoN DF4M7MlGbyOVNZnGCw== ---- END SSH2 PUBLIC KEY ----
This is a sample SSH2 public key generated in SSH Communications Security's SSH server with the RSA algorithm (ssh-keygen2 -t rsa), stored in ~/.ssh2/id_rsa_1024_a.pub:
---- BEGIN SSH2 PUBLIC KEY ---- Subject: miwa Comment: "1024-bit rsa, miwa@Rosalyn, Sun Sep 08 2002 23:00:14 -0500" AAAAB3NzaC1yc2EAAAADAQABAAAAgQDenNONzW2v+TB/ZeRHZvKRWJk24Lk7LsA4+uWsYL 5L+bNoPYV0oKD3UMYddEacM47gcSd2e1E511Wlx/+X0MjrvPqEIlqw9owkjwOukm38iISz qypT4uvawOW9GcKE7c5KH8BD9tfhvCkwZE+oAsJk3jfTBRSdOdxhvhF87RgbcQ== ---- END SSH2 PUBLIC KEY ----
This is a sample SSH1 public key generated in SSH Communications Security's SSH server with the RSA algorithm (ssh-keygen1), stored in ~/.ssh/identity.pub:
1024 35 150523262886747450533481402006467053649597280355648477085483985 71208317676866466089983419198328656197603216662844372018680273646986695 56178463737834517922511113363307584168444414723689895480461354097203955 14630983460536314249324093740941547077440748942146761033650932672516913 155150617149168536905710250843163 miwa@Rosalyn
After you have transferred your public key to the remote host, you have to let the remote host know that you want to allow public key authentication from your local host. How this is done depends on the SSH server. For OpenSSH, authorized public keys for SSH1 and SSH2 keys are stored in ~/.ssh/authorized_keys. Each line of a basic authorized_keys file contains a public key. Blank lines and lines starting with # are ignored. However, limitations can be further placed on an authorized public key using options listed in Table 21.3. A sample ~/.ssh/authorized_keys file follows:
1024 35 1557212985106595841799445393895896855201842965316926480116187178 479312752731786936426534362289883814829220699448695793008292191355256581 252483513540009913562286856320477786490006280726660808370019692878286941 832867913488270433630039854375920434585040342671329990216320744276783576 66438835891174723508102956387 miwa@brezup ssh-dss AAAAB3NzaC1kc3MAAACBALPMiCqdPDGxcyB1IwPrPXk3oEqvpxR62EsspxGKGGbO M6mf60i1hwTvjZzDhUSR7ViGeCopKtjJIqn2ljgeLbhFsQUX2UyJ6A1cFVuef0x6GVAsybqb tJc8JBh41U+iSXJKppEY5BI+REMydpBXJf2qT/8yZeq3NPjiOiMb6TyjAAAAFQDYvvV4WQK1 Zu23q/7iLKg5j/zi5wAAAIBR7vgrQpjKW2cprIUJsnenTm4hnBrEO7NMUomjgezrY23iZdIS QlU1ESMgx9W9nnZstd2vjeqHDSmmcD2p/aGqhl3N1WlYk8zgFYYJilPwRxVm77Np/vXz/MQp ygJE7ToXGvfHqVmdBpUyakyfx6DveWhFPis1Ab8N1RCPWm6PMwAAAIAytHjAAMYscqX2tl4i cw3oOku3HIvoHBCx9D6Q9LjCqt7DqqgMN2e5vuvNz0hzqBaBDJsjNA/A4bI88ZrgLhfJM/Nh s2xkcb7AYeHEtuGKVbsbB0EjsECtLRHydfmk3wDQjUVT92HsodFvsIl4Je7seWUuiAEe0V1x fF7XrXuwNQ== miwa@hobbes
For an SSH1 server by SSH Communications Security, the authorized public keys are also stored in ~/.ssh/authorized_keys. An SSH2 server by SSH Communications Security, however, stores references to files that contain authorized public keys in ~/.ssh2/authorization. Here is a sample ~/.ssh2/authorization file:
Key hobbes.pub Key ryoohki.pub
As an example, suppose that you want to allow public key authentication from a machine running an SSH Communications Security SSH2 server. First, generate a key-pair on the remote SSH2 machine using ssh-keygen2. Then transfer the public key of the key-pair to your Mac OS X machine by whatever method you choose.
In this case, because you want to allow public key authentication from a machine running a non-OpenSSH SSH server, you have to convert the public key file that was transferred to something compatible with your OpenSSH server. The ssh-keygen utility can convert between SSH formats. Run a command of the following form:
ssh-keygen -i -f <transferred_public_key> > <converted_transferred_public_key>
The preceding statement imports the transferred public key file and directs the converted output to a file specified by <converted_transferred_public_key>. We recommend including the name of the remote host in your filename to make things easier for you. OpenSSH's ssh-keygen can also export its keys to the IETF SECSH format.
Then add that file to the ~/.ssh/authorized_keys file, the file that contains your public keys from machines authorized to connect via public key authentication. This can be done in whatever way you feel most comfortable. Issuing the following statement does this quite neatly:
cat <converted_transferred_public_key> >> .ssh/authorized_keys
Now that the public key from the non-OpenSSH machine has been transferred and converted to a format used by OpenSSH, you can log in to your Mac OS X machine from the remote host via pubic key authentication.
Logging in to a machine running a non-OpenSSH SSH server from your Mac OS X machine is similar. First generate the key-pair on your Mac OS X machine using ssh-keygen. Then convert the public key file to the IETF SECSH format by running a command of the form:
ssh-keygen -e -f <public_key> > <converted_public_key>
Transfer the converted public key file to the remote host by whatever method you choose. Then add a reference to the ~/.ssh2/authorization file of the form:
Now that the public key generated on your Mac OS X machine has been transferred to the remote host running a non-OpenSSH SSH server, and a reference to it has been added to the ~/.ssh2/authorization file, you are logged in to the remote host via public key authentication.
The details provided here address logging in via public key authentication between the major different SSH servers using the SSH2 protocol. Because the SSH1 protocol is not under active development, we are not discussing the details involved there. However, if you need to connect to an SSH1 server via public key authentication, it is easier than what needs to be done for the SSH2 protocol. You do not have to convert the key formats. On the non-OpenSSH machine, the file that contains the public keys is ~/.ssh/authorized_keys, and you add public keys themselves to the file rather than references to the public key files.
If you don't like the command line, you might try Gideon Softworks' SSH Helper, available at http://www.gideonsoftworks.com/sshhelper.html. It is a freely available package.
Managing Your Keys with ssh-agent
The SSH suite of applications is wonderful for protecting your communications, but while entering a passphrase instead of a password for logins through ssh is only a minor inconvenience, repeating it over and over to copy files using scp can be a real annoyance. Thankfully, the designers thought of this and have created an auxiliary application that allows you to authenticate yourself once to it. It can then use the stored private keys and the passphrases associated with your SSH identities (SSH keypairs generated by ssh-keygen and authorized on another host), to authenticate to remote hosts for you automatically. Essentially, this software acts as your agent and responds for you whenever a remote host asks for your passphrase. This eliminates any need for you to respond to passphrase queries from remote hosts for which the agent knows a proper response, and can drastically decrease the effort involved in using the SSH applications.
If you're dealing with SSH on a daily basis, using ssh-agent is almost certainly the way you'll want to use the SSH software, as it will make your life much easier. The process for using the agent is simple as well, and can be summarized as follows:
However, although the difference in practice is significant, the difference in print is subtle. Previously in this chapter you've learned how to perform all the steps necessary to work through SSH, but for the sake of clarity with respect to what ssh-agent can actually do for you, we'll recap from the position of a user who's never used SSH to authenticate to remote hosts. In the examples that follow, we've left the prompt intact so that you can tell which machine and directory we're working in. The input/output fragments that follow were collected as a single stream of actions by our test user miwa, and we've split them up to intersperse some comments on what he's doing. If you follow along, by the end of this section you'll have set up a user with two independent SSH identities that can be used to authenticate against both ssh.com and openssh.org type sshd servers.
The end demonstration is almost anticlimactic, but it's what miwa doesn't do here that's significant. It looks like there's no authentication as though ryoko and creampuf simply allowed him to slogin in without bothering to check his credentials. This isn't the case. His ID was validated, but it was ssh-agent acting as his assistant that answered the query, and responded with the appropriate credentials. ssh-agent will continue to do so for any SSH commands that are run in this terminal, or for any other terminal that has had the environment variables set so that SSH commands run in it, can find the ssh-agent to talk to it.
Table 21.4 provides documentation for ssh-agent. Table 21.5 provides documentation for ssh-add.
A Better-Looking, More Helpful Butler: SSH Agent (the GUI Version)
If you're comfortable with the risks that using ssh-agent brings, there's a quite useful GUI tool that you might want to consider using. It, the Mac OS X Keychain, and some Terminal.app features all working together can make for wonderfully convenient secure remote connections. Xander Schrijen is actively developing a quite useful front end to the ssh-agent command-line utility, and endowing it with some nice auxiliary functions. SSH Agent acts sort of like a meta-agent for ssh-agent. It provides a GUI front end for the features of ssh-agent, and further can be configured to use your login credentials to store your passphrases in the Mac OS X Keychain, thereby allowing for ssh-agent functionality without you needing to do anything but successfully log in. To try out SSH Agent, download it from http://www.phil.uu.nl/~xges/ssh/ and follow the Quick-Start installation instructions. SSH Agent does take up room on your Dock. If you would prefer to have your agent run in the background, you might be more interested in SSHKeychain, available from http://www.sshkeychain.org/. It functions in the background, but is still available as a menu item. Both of these are simply interfaces to the ssh-agent command-line application, which is preinstalled and can be configured and used entirely without the GUI. Perform the following steps:
Initially, it will appear as shown in Figure 21.6. Click on the Add Identity button and the dialog shown in Figure 21.7 will appear. The IDs shown in this dialog should be familiar from our recap of miwa's SSH key generation earlier in this section. Select the private key from the keypair for any identity you want to use by default. In this example, we're adding both IDs that miwa created earlier.
Figure 21.6. Like ssh-agent, out of the box, SSH Agent knows no identities.
Figure 21.7. Clicking the Add Identity button allows you to select among any SSH identities that you've previously created. There's also a New Identity function under the File menu where you can create key pairs in SSH Agent from the beginning. Here, you need to select the private keys of each key-pair you want to use.
After you've selected the identities to add, the IDs will appear in the Default Identities tab, as shown in Figure 21.8.
Figure 21.8. The Default Identities pane after adding some IDs.
Go back to the Startup pane and select Add Default Identities as shown in Figure 21.9, and then quit SSH Agent again.
Figure 21.9. Setting the final preference that you need to configure before you can start making use of SSH Agent.
When you start SSH Agent again, you'll see a dialog as shown in Figure 21.10, where SSH Agent is asking you for the passphrase for an ID. Pay attention to the path shown for the identity, as SSH Agent will ask you for the passphrase for each identity you've configured it to load by default. Figure 21.11 shows what SSH Agent looks like after you've successfully supplied the requested passphrases.
Figure 21.10. SSH Agent prompts for the passphrases for each identity you've asked it to hold for you.
Figure 21.11. After you've supplied the requested passphrases, SSH Agent shows the loaded identities. From this window (which you can bring up from the Agent menu if the window is closed), you can also load additional nondefault identities selectively and as needed.
Now, if you start a terminal you can use the credentials held by SSH Agent, and you don't even need to execute the setenv commands like you needed to for the command-line ssh-agent (see Figure 21.12).
Figure 21.12. Now SSH Agent can provide you with the conveniences of ssh-agent, without you needing to set environment variables. This is nice, but the good part is still to come.
If you'd like to avoid even the work of having to enter the passphrases once at the startup of SSH Agent, you can select the Add to Keychain option shown in Figure 21.10, and the passphrases you enter for your identities will be saved in your Keychain. If you do this, your default identities will be loaded automatically when you start SSH Agent, and you won't need to enter the passphrases for them again.
Combining this capability with some of the capabilities of Terminal.app is where the big payoff in ease-of-use comes in. Terminal.app has an infrequently-used function under the File menu listed as New Command. This function gives you the ability to execute a command and open a Terminal window containing the executing results of that command. Figure 21.13 shows it being used to set up a slogin session to 192.168.1.200.
Figure 21.13. Setting up a Terminal session to run a command. Usually, you would just run the command in a Terminal session yourself, but this use is special.
Not surprisingly, the result of running the command in a shell, is a connection to creampuf (192.168.1.200). The neat thing is that we can now use another little-used feature of Terminal.app to save this terminal. Select the Save As item under Terminal.app's File menu. This will bring up a dialog like the one shown in Figure 21.14. In this dialog, provide a useful name that will help you remember where these Terminal settings will take you. Also, remember to set the save location to some place that you'll actually find useful.
Figure 21.14. Saving a Terminal.app terminal session. This isn't saving the contents it's saving what the terminal is doing.
And finally the nifty part. Figure 21.15 shows what miwa's done with his SSH Agent supplied identities, and with saved Terminal.app terminal sessions. The two icons shown in the Dock, one of which is labeled slogin_ryoko.term, is a saved terminal file for one of miwa's IDs. The icon next to it is another saved .term file that miwa created for his creampuf ID. He's applied interesting icons to each to make them a bit more distinctive than the default little white rectangle icons they come with. Clicking on either will launch a Terminal session, using the command miwa set for it from the New Command menu item. That command will query the running SSH Agent, get the appropriate passphrase for miwa as necessary, and the connection to the remote server will be made with no further interaction needed on miwa's part.
Figure 21.15. Saved .term files allow you to rerun their saved commands, in this case, saved slogin commands, which SSH Agent will allow to create secure connections with no further authentication required.
Single-click secure, encrypted connections to remote servers. What could be slicker than that?
SSH Clients for Windows, Traditional Mac OS, and Mac OS X
From other Unix machines with an SSH server installed, you should be able to use ssh or slogin to connect to your Mac OS X machine from a remote location. But you don't need a Unix machine to connect to your Mac OS X machine. Windows and traditional Mac OS clients are also available. This section includes a listing of popular client software, including a brief description of each client's features.
A number of Windows SSH clients are available. Among the available clients are
A few ssh clients are available for the traditional Mac OS. The clients that work in the traditional Mac OS probably also work in Mac OS X's classic mode. As a matter of fact, to tunnel connections in classic mode, you will need one of these clients with tunneling capabilities. Available clients include
Mac OS X
Mac OS X, of course, has the command-line ssh tools available. However, if you are new to the command line, you might also be wondering whether any SSH GUI tools are available. As you might recall from Chapter 12, even Terminal.app provides some basic SSH GUI tools. For sftp and scp alternatives, you should also check whether your favorite FTP client includes or will include such support. Available clients include
|< Day Day Up >|