Maximum Mac OS X Security

In addition to allowing you to log in remotely to another machine running an SSH server, SSH can be used for tunneling connections from one machine to another, securely transferring files, and public key authentication. Table 14.5 lists the primary tools in the SSH suite and their function.

Table 14.5. Primary Utilities in OpenSSH

Tunnel Encryption

As you saw in Chapter 12, "FTP Security," one of the features of the SSH protocol is its ability to tunnel connections. In other words, you can set up an encrypted channel between machines and use the encrypted channel to send an otherwise insecure protocol. In Chapter 12, you saw in great detail how to restrict access to the FTP server and to tunnel a connection to the server. Services that you might also be interested in tunneling include POP, IMAP, and X11. Recall that X11 forwarding is off by default in the /etc/sshd_config file.

To summarize what was discussed in that chapter, first restrict access to the server that is to be tunneled. This is done by adding a line to the /etc/hosts.allow file that restricts access to the machine with the server. For example, as you saw earlier for an FTP server, this can be done as

in.ftpd: <machine-IP> 127.0.0.1 localhost: allow in.ftpd: deny

if you are only using the /etc/hosts.allow file, or as

in.ftpd: <machine-IP> 127.0.0.1 localhost

if you are using the traditional /etc/hosts.allow and /etc/hosts.deny files.

Alternatively, if you are using the access restriction capabilities of xinetd , you could add a line to the /etc/xinetd.d/ftp file like

only_from = <machine-IP> 127.0.0.1 localhost

Next , use an SSH client to set up a tunnel. For Windows, traditional Mac OS, or Mac OS X Classic mode, this is a matter of using an SSH client to enter the local port to use on your machine, the name of the server, and the port number to use on the server. From a Unix machine, such as the native Mac OS X side of your Macintosh, use ssh with a port forwarding option. The following example sets up a tunnel without requiring that you have a terminal connection:

% slogin 192.168.1.17 -l sage -N -L 2121:192.168.1.17:21 sage@192.168.1.17'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 enables you 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, then 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:

% ftp localhost 2121 Connected to localhost.biosci.ohio-state.edu. 220 192.168.1.17 FTP server (lukemftpd 1.1) ready. Name (localhost:joray): sage 331 Password required for sage. 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> passive Passive mode on. ftp> get test-1.tiff local: test-1.tiff remote: test-1.tiff 227 Entering Passive Mode (192,168,1,17,192,9) 150 Opening BINARY mode data connection for 'test-1.tiff' (431888 bytes). 226 Transfer complete. 431888 bytes received in 0.516 seconds (837284 bytes/s) ftp> quit 221- Data traffic for this session was 431888 bytes in 1 file. Total traffic for this session was 432551 bytes in 1 transfer. 221 Thank you for using the FTP service on 192.168.1.17.

In short, the basic procedure to follow for tunneling a given protocol is as follows :

1. Optionally restrict access by setting up the server to accept connections from only the server machine. Depending on your circumstances, you may have to have this restriction anyway.

2. Set up an SSH client with port and server information.

3. Set up the client for the service being tunneled with the local port number to use and localhost or 127.0.0.1 as the host.

4. Use the client for the tunneled service as you ordinarily would.

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. However, if this doesn't quite work for you, it may also be necessary for the remote host to add a line to /etc/hosts.allow to enable your IP address to have access to the sshdfwd-X11 service.

Figure 14.1 shows remotely running X11 applications being displayed to an OS X machine via SSH tunneling.

Secure File Transfer

As you also saw in Chapter 12, the OpenSSH package also includes two utilities for transferring files: scp (secure copy) and sftp (secure FTP). Table 14.6 provides documentation on the options available to scp . Table 14.7 provides documentation on options available to the command line in sftp as well as commands available interactively.

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:

% scp sage@192.168.1.17:terminal/term-display-1.tiff ./ sage@192.168.1.17's password: term-display-1.tiff 100% ******************************** 900 KB 00:01

While the transfer occurs, the percentage and amount transferred increases over time. You cannot use scp to copy files from your OS X machine unless you have activated the SSH server.

Table 14.6. Options for scp

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 :

sftp [ <usesrname> @] <remote_host>

Here is sample output from an interactive sftp session:

% sftp sage@192.168.1.17 Connecting to 192.168.1.17... sage@192.168.1.17'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 OS X machine unless you have activated the SSH.

Table 14.7. Documentation for sftp

Public Key Authentication

In addition to the standard method of user authenticationa username and passwordSSH 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 that is protected with a passphrase. Then the user transfers the public key to the remote host to which she would like 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.

The procedure for enabling public key authentication is similar for both SSH1 and SSH2. Table 14.8 provides documentation on options for ssh-keygen , the utility that generates key pairs. Table 14.9 provides descriptions for files used in public key authentication. To enable public key authentication, do the following:

1. Generate a key pair on the host from which you want to access another host. (For example, call the host from which you want to connect the local host, and the host to which you want to connect the remote host.) Use a good passphrase to protect your key. It is recommended that a good passphrase be 1030 characters long, and not simple sentences or otherwise easily guessable. Include a mix of uppercase, lowercase, numeric, and nonalphanumeric characters .

2. Transfer the public key of the key pair generated on the local host to the remote host. The public key is public, so you can use any method necessary to transfer it to the remote host.

3. Add the public key you just transferred to the file on the remote host that stores public keys.

4. Test logging into the remote host. You should now be prompted for the passphrase that you used to generate your key pair, because the private key of the local host is paired with its public key that was transferred to the remote host.

Table 14.8. Options for ssh-keygen

Table 14.9. Files Used in Public Key Authentication

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, which are the other variety 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.

To give you an idea of how the various public keys look, some sample public keys are shown here. The samples were made using the defaults, except for this first key, which does not have a default for the algorithm. This 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/

This is a sample SSH1 public key generated in OpenSSH with the RSA algorithm ( ssh-keygen t rsa ), stored as ~.ssh/identity.pub :

1024 35 1557212985106595841799445393895896855201842965316926480116187178 479312752731786936426534362289883814829220699448695793008292191355256581 252483513540009913562286856320477786490006280726660808370019692878286941 832867913488270433630039854375920434585040342671329990216320744276783576 66438835891174723508102956387 miwa@Sage-Rays-Computer.local.

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 if you use the options listed in Table 14.10. The following is a sample ~/.ssh/authorized_keys file:

1024 35 1557212985106595841799445393895896855201842965316926480116187178 479312752731786936426534362289883814829220699448695793008292191355256581 252483513540009913562286856320477786490006280726660808370019692878286941 832867913488270433630039854375920434585040342671329990216320744276783576 66438835891174723508102956387 miwa@Sage-Rays-Computer.local. 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 SSH Communications Security SSH1 server, 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 ~/.ssh/authorization file:

Key hobbes.pub Key ryoohki.pub

As an example, suppose 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 by 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 OS X machine is similar. First generate the key pair on your OS X machine by 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 form's ~/.ssh2/authorization file:

Key <public_key_filename>

Now that the public key generated on your 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 can log 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/. It is a freely available package.

Table 14.10. Options for ~/.ssh/authorized_keys

A Butler to Hold Your Wallet: ssh-agent

The SSH suite of applications is wonderful for protecting your communications, but although entering a passphrase instead of a password for logins through ssh is only a minor inconvenience, repeating it over and over to copy files with scp can be a real annoyance. Thankfully, the designers thought of this, and have created an auxiliary application that enables you to authenticate yourself once to it, and it can then use the stored private keys and the passphrases associated with your SSH identities (SSH key pairs 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; it will make your life much easier. The process for using the agent is simple as well, and can be summarized as follows:

1. Start the ssh-agent .

2. Set up your environment so that SSH applications can find the agent.

3. Add identities to the agent.

4. Use SSH applications ( slogin , scp , etc.), and never get asked for your passphrase.

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 in which machine and directory we're working. 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.

1. Look first at what files miwa has in his ~/.ssh directory.

   [Sage-Rays-Computer:~] miwa% ls -l .ssh ls: .ssh: No such file or directory

2. We're starting with a clean slatewe've deleted miwa 's ~/.ssh directory so that it's as if he's never used the SSH software before.

   [Sage-Rays-Computer:~] miwa% ssh-keygen -t rsa -b 1024 Generating public/private rsa key pair. Enter file in which to save the key (/Users/miwa//.ssh/id_rsa): Created directory '/Users/miwa//.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /Users/miwa//.ssh/id_rsa. Your public key has been saved in /Users/miwa//.ssh/id_rsa.pub. The key fingerprint is: f4:ab:15:d4:47:54:5b:4b:d4:79:be:e6:f7:f3:ca:6d miwa@Sage-Rays-Computer.local.

3. To use SSH applications, miwa needs keys. Create his default key as an RSA key of 1024 bits. The " // " in the path to his key file is an artifact of the way the software determines paths, and will collapse safely to a single / . Enter a passphrase for miwa , but notice that it's not echoed to the screen.

   [Sage-Rays-Computer:~] miwa% ls -l .ssh total 16 -rw------- 1 miwa staff 951 Feb 17 13:43 id_rsa -rw-r--r-- 1 miwa staff 240 Feb 17 13:43 id_rsa.pub

4. In his ~/.ssh directory, there are now two files, containing the private and public key pair for his default identity.

   [Sage-Rays-Computer:~] miwa% slogin ryoko.biosci.ohio-state.edu miwa@ryoko.biosci.ohio-state.edu's password: Last login: Mon Feb 17 2003 13:51:04 -0500 from cvl232015.columb You have mail. ryoko miwa 1 >ls -l .ssh2 .ssh2: No such file or directory ryoko miwa 2 >mkdir .ssh2 ryoko miwa 3 >exit Connection to ryoko.biosci.ohio-state.edu closed.

5. miwa logs into ryoko.biosci.ohio-state.edu , using his password for the system. ryoko is a Sun Enterprise Server running ssh.com 's version of the SSH software. It doesn't keep its key files in the same place as does our Macintosh's openssh.org version. miwa creates the required ~/.ssh2 directory in his home directory on ryoko and then logs off the machine. For the best security, we recommend disabling passworded logins from the network entirely, and accepting only passphrases, but this requires physical access to both machines for at least a little while, or some other way of transferring a public key without being able to log in to the remote machine via the network.

   [Sage-Rays-Computer:~] miwa% cd .ssh [Sage-Rays-Computer:~/.ssh] miwa% ls -l total 24 -rw------- 1 miwa staff 951 Feb 17 13:43 id_rsa -rw-r--r-- 1 miwa staff 240 Feb 17 13:43 id_rsa.pub -rw-r--r-- 1 miwa staff 633 Feb 17 13:45 known_hosts [Sage-Rays-Computer:~/.ssh] miwa% ssh-keygen -e -f id_rsa ---- BEGIN SSH2 PUBLIC KEY ---- Comment: "1024-bit RSA, converted from OpenSSH by miwa@Sage-Rays-Computer.local." AAAAB3NzaC1yc2EAAAABIwAAAIEAttgqNkpzwf991Siz3EpJsPTt2cHt3aecCqc542+rIw 8P3PdmQP78+uFHiFMEQMr5/NcoxPxDWS1QGb06iihYt3j8QoxTbRD/b7b9mdHHDzJekCH2 jSonnVCh+XUsCAG8KeZ64VZuLEbXOf9VRlBZC2T7MWt6woMgVJvvKqyJVuk= ---- END SSH2 PUBLIC KEY ----

6. miwa needs to get the public key for the identity he wants to use on ryoko into a form that ryoko 's sshd can understand. Pleasantly, ssh-keygen cannot only generate keys, but it can also translate them into the standard format that ssh.com 's server version wants. A known_hosts file has appeared in miwa 's .ssh directory along with his id_rsa identity files. In this file is recorded the public host key for ryoko .

   [Sage-Rays-Computer:~/.ssh] miwa% ssh-keygen -e -f id_rsa > home_rsa.ietf [Sage-Rays-Computer:~/.ssh] miwa% ls -l total 32 -rw-r--r-- 1 miwa staff 347 Feb 17 13:57 home_rsa.ietf -rw------- 1 miwa staff 951 Feb 17 13:43 id_rsa -rw-r--r-- 1 miwa staff 240 Feb 17 13:43 id_rsa.pub -rw-r--r-- 1 miwa staff 633 Feb 17 13:45 known_hosts

7. Using ssh-keygen , miwa writes out an IETF formatted version of the public key for his id.rsa key, and puts it in his .ssh directory. Because the SSH implementation on Mac OS X won't use this key for anything, he could actually store it just about anywhere , but this seems like as good and safe a place as any.

   [View full width]

   [View full width]

   [Sage-Rays-Computer:~/.ssh] miwa% scp ./home_rsa.ietf miwa@ryoko.biosci.ohio-state.edu:. ssh2/home_rsa.ietf miwa@ryoko.biosci.ohio-state.edu's password: scp: warning: Executing scp1 compatibility. home_rsa.ietf 100% **************************** 347 00:00

8. miwa copies the key to ryoko by using scp . Because it's a public key, it wouldn't be a problem even if he had to copy it over a protocol where data is visible. If passworded logins are blocked, this key transfer needs to be done in some other fashion, such as transporting it on removable media.

   [Sage-Rays-Computer:~/.ssh] miwa% slogin ryoko.biosci.ohio-state.edu miwa@ryoko.biosci.ohio-state.edu's password: Last login: Mon Feb 17 2003 13:53:54 -0500 from cvl232015.columb You have mail. ryoko miwa 1 >ls -l .ssh2 total 2 -rw-r--r-- 1 miwa class 347 Feb 17 14:01 home_rsa.ietf ryoko miwa 2 >cd .ssh2 ryoko .ssh2 3 >cat >> authorization Key home_rsa.ietf ^D

9. An authorization file must be created on ryoko , listing the key miwa just transferred as valid for logins. miwa just cat s the line in append mode onto his authorization file. The file doesn't exist, so it'll get created, but if it did exist, this Key line would simply be added as new data at the end of the file. The cat command is terminated with a Control-D on a line by itself.

   ryoko .ssh2 4 >ls -l total 4 -rw-r--r-- 1 miwa class 18 Feb 17 14:02 authorization -rw-r--r-- 1 miwa class 347 Feb 17 14:01 home_rsa.ietf ryoko .ssh2 5 >chmod 600 authorization home_rsa.ietf ryoko .ssh2 6 >ls -l total 4 -rw------- 1 miwa class 18 Feb 17 14:02 authorization -rw------- 1 miwa class 347 Feb 17 14:01 home_rsa.ietf ryoko .ssh2 7 >cat authorization Key home_rsa.ietf ryoko .ssh2 8 >exit Connection to ryoko.biosci.ohio-state.edu closed.

10. The authorization file now exists, and contains the data expected. Even though it's a public key and theoretically can't be usefully abused, miwa chmod s both files in his .sshd directory so that only he can read them, just to be sure.

    [Sage-Rays-Computer:~/.ssh] miwa% slogin ryoko.biosci.ohio-state.edu Enter passphrase for key '/Users/miwa//.ssh/id_rsa': Last login: Mon Feb 17 2003 14:05:00 -0500 from cvl232015.columb You have mail. ryoko miwa 1 >exit Connection to ryoko.biosci.ohio-state.edu closed.

11. Back on Sage's computer, miwa can now slogin to ryoko , and be asked for a passphrase rather than his considerably weaker password.

    [View full width]

    [View full width]

    [Sage-Rays-Computer:~/.ssh] miwa% ssh-keygen -t rsa -b 1024 Generating public/private rsa key pair. Enter file in which to save the key (/Users/miwa//.ssh/id_rsa): /Users/miwa//.ssh/ internal_rsa Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /Users/miwa//.ssh/internal_rsa. Your public key has been saved in /Users/miwa//.ssh/internal_rsa.pub. The key fingerprint is: 62:47:b5:71:2b:23:08:ee:87:e2:cc:7d:0b:ce:4d:44 miwa@Sage-Rays-Computer.local.

12. For some reason, miwa wants another, separate identity for use on his internal (private) network. Perhaps it's because he's going to allow (against our good advice) other users to log in to his account and use it for connecting to other machines on the internal network. By using a separate identity, and giving out the passphrase only to his internal identity, he can mitigate the danger in this scheme and protect his external identity. Here, miwa 's chosen to create it into the nondefault file internal_rsa , again as a 1024-bit RSA key.

    [Sage-Rays-Computer:~/.ssh] miwa% ls -l total 48 -rw-r--r-- 1 miwa staff 347 Feb 17 13:57 home_rsa.ietf -rw------- 1 miwa staff 951 Feb 17 13:43 id_rsa -rw-r--r-- 1 miwa staff 240 Feb 17 13:43 id_rsa.pub -rw------- 1 miwa staff 951 Feb 17 14:11 internal_rsa -rw-r--r-- 1 miwa staff 240 Feb 17 14:11 internal_rsa.pub -rw-r--r-- 1 miwa staff 633 Feb 17 13:45 known_hosts

13. Now there are files in ~miwa/.ssh/ for both his default id_rsa identity and his internal_rsa identity. miwa needs to transfer the public key from the internal_rsa key pair to any of the private, internal-network hosts he wants to be able to access via passphrase. In this case, 192.168.1.200 , otherwise known as creampuf , will be used as an example.

    [Sage-Rays-Computer:~/.ssh] miwa% 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 f3:62:16:8e:25:7f:75:ab:4c:cd:99:5d:39:bc:3c:b7. 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. miwa@192.168.1.200's password: Welcome to Darwin! [creampuf:~] miwa% ls -l .ssh ls: .ssh: No such file or directory [creampuf:~] miwa% mkdir .ssh [creampuf:~] miwa% touch .ssh/authorized_keys [creampuf:~] miwa% chmod 600 .ssh/authorized_keys [creampuf:~] miwa% exit Connection to 192.168.1.200 closed.

14. Again, miwa hasn't logged in to this host before, so creating the directory to contain SSH keys is necessary. This time it's a Mac OS X machine, so it uses the openssh.org way of specifying authorized remote users, that being a single authorized_keys file of ( concatenated ) authorized keys. miwa creates the file, and sets its permissions to owner read/write only.

    [Sage-Rays-Computer:~/.ssh] miwa% ls -l total 48 -rw-r--r-- 1 miwa staff 347 Feb 17 13:57 home_rsa.ietf -rw------- 1 miwa staff 951 Feb 17 13:43 id_rsa -rw-r--r-- 1 miwa staff 240 Feb 17 13:43 id_rsa.pub -rw------- 1 miwa staff 951 Feb 17 14:11 internal_rsa -rw-r--r-- 1 miwa staff 240 Feb 17 14:11 internal_rsa.pub -rw-r--r-- 1 miwa staff 856 Feb 17 14:13 known_hosts

15. Back on Sage's computer, the known_hosts file has grown because it's accumulated the host key from 192.168.1.200 now as well.

    [View full width]

    [View full width]

    [Sage-Rays-Computer:~/.ssh] miwa% scp internal_rsa.pub miwa@192.168.1.200:.ssh/ miwa_sage_rsa.pub miwa@192.168.1.200's password: internal_rsa.pub 100% **************************** 240 00:00 [Sage-Rays-Computer:~/.ssh] miwa% !slo slogin 192.168.1.200 miwa@192.168.1.200's password: Welcome to Darwin! [creampuf:~] miwa% cd .ssh [creampuf:~/.ssh] miwa% ls -l total 8 -rw------- 1 miwa staff 0 Feb 17 14:17 authorized_keys -rw-r--r-- 1 miwa staff 240 Feb 17 14:19 miwa_sage_rsa.pub [creampuf:~/.ssh] miwa% cat miwa_sage_rsa.pub >> authorized_keys [creampuf:~/.ssh] miwa% cat authorized_keys ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAr0JLpso1q7HrZ9EGiK8Gk4lvvxnV2GHAQ CACC4Pdf76NheY3df6+sAmDBhgJ/N8DGorYCmMpd5TdnZkSK+61V3LAtqGno1nFnmNgTy n8HDXm99hJJk0GGnXKi3s74RBqQEcQu3LQtlfJfQW3j51gC9c6XyVANRi53UlorxbADvc = miwa@Sage-Rays-Computer.local. [creampuf:~/.ssh] miwa% chmod 600 miwa_sage_rsa.pub [creampuf:~/.ssh] miwa% exit Connection to 192.168.1.200 closed.

16. miwa transfers his public key from his internal_rsa key pair to 192.168.1.200 , and saves it as miwa_sage_rsa.pub in his .ssh directory on 192.168.1.200 . It's good to come up with a standardized naming scheme for keys that gives you some idea of what user the key was for, and from what host it will allow them access. In this case, because miwa might be allowing other users to log in to his account, he might eventually have many other users' public keys stored in his authorized_keys files in his various accounts around the internal network. Keeping a copy of each of them named in terms of who it allows access, and from which machine, enables him to sort through his authorized_keys file and delete entries if it becomes necessary to limit access in the future.

    After he's transferred his internal_rsa public key to creampuf , he logs in to creampuf (again using his password) and cats the key (in append mode) onto the end of his ~/.ssh/authorized_keys file. He also chmod s it to owner read/write onlyagain, just to be safe.

    [Sage-Rays-Computer:~/.ssh] miwa% cd ~ [Sage-Rays-Computer:~] miwa% slogin 192.168.1.200 miwa@192.168.1.200's password: ^C

17. Back on Sage's machine, miwa tests his setup and lands at a password prompt. That wasn't the expected behavior. Everything was copied over properly, so maybe it's something about slogin that miwa doesn't yet understandmaybe it's not smart enough to pick the correct identity credentials from the ones he's created, and it's trying to authenticate to the internal server with his default ID? Reading the man page, he discovers that you can specify an ID explicitly, and he tries that option.

    [Sage-Rays-Computer:~] miwa% slogin 192.168.1.200 -i internal_rsa Warning: Identity file internal_rsa does not exist. miwa@192.168.1.200's password: ^C

    Again, not the desired response, but this time it's a complaint that the identity doesn't exist. Perhaps slogin 's not smart enough to look in the default location for anything other than the default identity as well?

    [Sage-Rays-Computer:~] miwa% slogin 192.168.1.200 -i .ssh/internal_rsa miwa@192.168.1.200's password: Welcome to Darwin! [creampuf:~] miwa% tail -3 /var/log/system.log Feb 17 14:29:45 creampuf sshd[571]: Could not reverse map address 192.168.1.17. Feb 17 14:29:45 creampuf sshd[571]: Authentication refused: bad ownership or modes for directory /Users/miwa Feb 17 14:29:53 creampuf sshd[571]: Accepted password for miwa from 192.168.1.17 port 49182 ssh2

    Although it doesn't show up in print, there was actually a fairly long pause after miwa issued this slogin command before it brought up the password prompt. Clearly it knows about the ID; it didn't complain about the specification this time, so maybe something's wrong with the server on the remote host. A quick look at the diagnostics from sshd in system.log reveals the problem. There's something about the permissions of miwa 's home directory that sshd doesn't like, and it's therefore refusing to allow passphrased access.

    [creampuf:~] miwa% ls -ld /Users/miwa/ drwxrwxr-x 28 miwa staff 952 Feb 17 14:17 /Users/miwa/

    The problem is that miwa has been sloppy with security, and has left his home directory with write access for the staff group. This would enable a malicious user who is a member of group staff to potentially edit or overwrite files in miwa 's directory. Because this could allow her to modify miwa 's ~/.ssh/authorized_keys file without permission, sshd recognizes this as a security hole, and disables use of that file for authorization.

    [creampuf:~] miwa% chmod 755 . [creampuf:~] ls -ld /Users/miwa/ drwxr-xr-x 28 miwa staff 952 Feb 17 14:17 /Users/miwa/ [creampuf:~] miwa% exit Connection to 192.168.1.200 closed.

18. miwa changes the permissions on his home directory to disallow write access for anyone except himself, and logs out to try again.

    [Sage-Rays-Computer:~] miwa% slogin 192.168.1.200 -i .ssh/internal_rsa Enter passphrase for key '.ssh/internal_rsa': Welcome to Darwin!

19. Success! miwa can now log in to either ryoko.biosci.ohio-state.edu , or to 192.168.1.200 , and each uses an independent ID with independent passphrases. This brings us to the conclusion of the recap, and to where miwa uses ssh-agent to make his life easier by removing the need for him to constantly type passphrases to use SSH tools.

    [Sage-Rays-Computer:~] miwa% ssh-agent setenv SSH_AUTH_SOCK /tmp/ssh-QjvPgj3h/agent.607; setenv SSH_AGENT_PID 608; echo Agent pid 608;

20. When run, ssh-agent prints out some information regarding how it can be contacted, and forks itself into the background. At that point, it's your agent, ready and willing to answer passphrase requests for you, but it doesn't yet have copies of any of your credentials, and none of the software that needs access to your credentials knows how to find it. The information that it prints out (by default) is csh -syntax commands that will set up a shell so that SSH tools run in that shell can find the agent.

    To use the information, simply copy the lines that ssh-agent prints, and execute them as commands at the command-line prompt.

    [Sage-Rays-Computer:~] miwa% setenv SSH_AUTH_SOCK /tmp/ssh- QjvPgj3h/agent.607; [Sage-Rays-Computer:~] miwa% setenv SSH_AGENT_PID 608;

21. miwa runs the two setenv commands, and ignores the echo . The output of ssh-agent is designed so that you can wrap it into a script that calls it, and executes its suggested shell commands automatically. The echo is only there so that you get diagnostic output to your terminal if you use it in this fashion.

    Next, miwa must supply the credentials that he wants the agent to provide in response to queries from SSH programs. This is accomplished with the ssh-add command.

    [Sage-Rays-Computer:~] miwa% ssh-add Enter passphrase for /Users/miwa//.ssh/id_rsa: Identity added: /Users/miwa//.ssh/id_rsa (/Users/miwa//.ssh/id_rsa) [Sage-Rays-Computer:~] miwa% ssh-add .ssh/internal_rsa Enter passphrase for .ssh/internal_rsa: Identity added: .ssh/internal_rsa (.ssh/internal_rsa)

22. miwa uses ssh-add to add his default identity, and then to add his internal_rsa identity. Both identities require that he supply the passphrase, just as if he were logging in to the remote systems that accept these identities by using slogin .

    [View full width]

    [View full width]

    [Sage-Rays-Computer:~] miwa% ssh-add -L ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAttgqNkpzwf991Siz3EpJsPTt2cHt3aecCqc542+rIw8P3PdmQ P78+uFHiFMEQMr5/NcoxPxDWS1QGb06iihYt3j8QoxTbRD/b7b9mdHHDzJekCH2jSonnVCh+XUsC AG8KeZ64VZuLEbXOf9VRlBZC2T7MWt6woMgVJvvKqyJVuk= /Users/miwa//.ssh/id_rsa ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAr0JLpso1q7HrZ9EGiK8Gk4lvvxnV2GHAQCACC4Pdf76NheY3d f6+sAmDBhgJ/ N8DGorYCmMpd5TdnZkSK+61V3LAtqGno1nFnmNgTyn8HDXm99hJJk0GGnXKi3s74 RBqQEcQu3LQtlfJfQW3j51gC9c6XyVANRi53ULorxbADvc= .ssh/internal_rsa

23. Just for good measure, miwa checks the credentials that ssh-agent is holding for him, and then goes on to test whether slogin now works without requiring him to supply his passphrase:

    [Sage-Rays-Computer:~] miwa% slogin ryoko.biosci.ohio-state.edu Last login: Mon Feb 17 2003 14:09:49 -0500 from cvl232015.columb You have mail. ryoko miwa 1 >exit Connection to ryoko.biosci.ohio-state.edu closed. [Sage-Rays-Computer:~] miwa% slogin 192.168.1.200 Welcome to Darwin! [creampuf:~] miwa% exit Connection to 192.168.1.200 closed.

The end demonstration is almost anticlimactic, but it's what miwa doesn't do here that's significant. It looks as if 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, and can find the ssh-agent to talk to it.

Table 14.11 provides a listing of options for ssh-agent . Table 14.12 provides a listing of options for ssh-add .

Table 14.11. Options for ssh-agent

Table 14.12. Options 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, then 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 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. At this time, this means performing the following steps:

Download the software from http://www.phil.uu.nl/~xges/ssh/.

Mount the disk image and copy the SSH Agent application to some convenient place on your drive. If you'd like it to be available to all your users, putting it in /Applications/ would be appropriate. Eject the disk image when you're done.

Run the SSH Agent application and open the Preferences panel.

In the Startup tab, shown in Figure 14.2, check the Make Agent Global setting.

In the Environment tab, use the Add Variable button to add a variable named CVS_RSH and set its value to ssh .

Log out, log back in, and restart SSH Agent . Open the Preferences panel again, and go to the Default Identities pane. Initially, it will appear as shown in Figure 14.4. Click on the Add Identity button and the dialog shown in Figure 14.5 appears. The IDs shown in this dialog should be familiar from the recap of miwa 's SSH key generation earlier in this section. Select the private key from the key pair for any identity you want to use by default. In this example, we're adding both IDs that miwa created earlier.

After you've selected the identities to add, the IDs appear in the Default Identities tab, as shown in Figure 14.6.

Go back to the Startup pane and select Add Default Identities, as shown in Figure 14.7, and then quit SSH Agent again.

When you start SSH Agent again, you'll see a dialog as shown in Figure 14.8, 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 14.9 shows what SSH Agent looks like after you've successfully supplied the requested passphrases.

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 as you needed to for the command-line ssh-agent . Figure 14.10 shows our miwa user making use of these IDs in a terminal.

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 seen in Figure 14.8, 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 enables you to execute a command and open a terminal window containing the executing results of that command. Figure 14.11 shows it being used to set up an slogin session to 192.168.1.200 .

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 you 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 brings up a dialog like the one shown in Figure 14.12. In this dialog, provide a useful name that will help you remember where these terminal settings take you. Also, remember to set the save location to some place that you'll actually find useful.

And finally the nifty part. Figure 14.13 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 launches a terminal session, using the command miwa set for it from the New Command menu item. That command queries the running SSH Agent , gets 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.

Single-click, secure, encrypted connections to remote servers. What could be slicker than that?