Accessing Mac OS X Remotely Using Apple Remote Desktop

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

Table 21.1. Primary Utilities in OpenSSH

Utility

Description

sshd

SSH server.

ssh

SSH client.

sftp

An interactive secure file transfer program.

scp

A copy program for copying files between hosts.

sftp-server

SFTP server subsystem started automatically by sshd.

ssh-keygen

A utility that generates keys for public key authentication.

ssh-agent

Authentication agent that manages keys for public key authentication users so that they don't have to enter a passphrase when logging in to another machine. It starts at the beginning of an X11 session or login session, and windows and programs start as its children.

ssh-add

Utility that adds keys to the ssh-agent.


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 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 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:

 sftp [<username>@]<remote_host> 

Here is sample output from an interactive sftp session:

 creampuf:~ nermal$ 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 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 sageray@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 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 ralph@rosalyn.biosci.ohio-state.edu'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:

1.

Optionally restrict access by setting up the server to accept connections only from 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. 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

Create a Tunnel to:

192.168.1.17

Service or Port:

21

Local Port:

2121

Tunnel Host:

192.168.1.17

Username:

sageray

Port:

(Can be left blank if the remote host's SSH server is running on the standard SSH port, 22.)


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:

1.

Generate a key-pair on the host from which you want to access another host. (We will 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 10 30 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. Depending on the SSH servers involved, you might have to convert your key to a different format first.

3.

Add the public key you just transferred to the file on the remote host that stores public keys. Depending on the version of SSH that the remote host is running, this could entail actually adding the key to a file, or just adding a reference to the key in the appropriate file.

4.

Test logging in to 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 21.2. Select Documentation for ssh-keygen

ssh-keygen

Tool for authentication key generation, management and conversion.

ssh-keygen [-q] [-b <bits>] -t <type> [-N <new_passphrase>] [-C <comment>]

[-f <output_keyfile>]

ssh-keygen -p [-P <old_passphrase>] [-N <new_passphrase>] [-f <keyfile>]

ssh-keygen -i [-f <input_keyfile>]

ssh-keygen -e [-f <input_keyfile>]

ssh-keygen -y [-f <input_keyfile>]

ssh-keygen -c [-P <passphrase>] [-C <comment>] [-f <keyfile>]

ssh-keygen -l [-f <input_keyfile>]

ssh-keygen -B [-f <input_keyfile>]

ssh-keygen generates, manages, and converts authentication keys for ssh. ssh-keygen can create RSA keys for use by 1, and RSA or DSA keys for use by SSH2. The type of key to be generated is specified with the -t option.

Normally each user who wants to use SSH with RSA or DSA authentication runs this once to create the authentication key in $HOME/.ssh/identity, $HOME/.ssh/id_dsa, or $HOME/.ssh/id_rsa. Additionally, the system administrator may use this to generate host keys.

-b <bits>

Specifies the number of bits in the key to create. Minimum is 512 bits. Generally 1024 bits is considered sufficient, and key sizes above that no longer improve security but make things slower. Default is 1024 bits.

-e

Reads a private or public OpenSSH key file and prints the key in a SECSH Public Key File Format to stdout. This option allows exporting keys for use by several commercial SSH implementations.

-f <filename>

Specifies the filename of the key file.

-i

Reads an unencrypted private (or public) key file in SSH2-compatible format and prints an OpenSSH-compatible private (or public) key to stdout. ssh-keygen also reads the SECSH Public Key File Format. This option allows importing keys from several commercial SSH implementations.

-p

Requests the changing of the passphrase of a private key file instead of creating a new private key.

-t <type>

Specifies the type of the key to create. The possible values are rsa1 for protocol version 1 and rsa or dsa for protocol version 2.

-C <comment>

Provides the new comment.

-N <new_passphrase>

Provides the new passphrase, <new_passphrase>.

-P <passphrase>

Provides the (old) passphrase, <passphrase>.


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 

Table 21.3. Options for ~/.ssh/authorized_keys

Option

Function

From="pattern-list"

Specifies that in addition to RSA authentication, the canonical name of the remote host must be present in the comma-separated list of patterns. * and ? serve as wildcards. The list may also contain patterns negated by prefixing them with !. If the canonical hostname matches a negated pattern, the key is not accepted.

Command="command"

Specifies that the command is executed whenever this key is used for authentication. The command supplied by the user (if any) is ignored. The command is run on a pty if the client requests a pty; otherwise, it is run without a tty. If an 8-bit clean channel is required, one must not request a pty or should specify no-pty. A quote may be included in the command by quoting it with a backslash. This option might be useful to restrict certain RSA keys to perform just a specific operation. An example might be a key that permits remote backups but nothing else. Note that the client may specify TCP/IP and/or X11 forwarding unless they are explicitly prohibited. Note that this option applies to shell, command, or subsystem execution.

environment="NAME=value"

Specifies that the string is to be added to the environment when logging in using this key. Environment variables set this way override other default environment values. Multiple options of this type are permitted. This option is automatically disabled if UseLogin is enabled.

no-port-forwarding

Forbids TCP/IP forwarding when this key is used for authentication. Any port forward requests by the client will return an error. This might be used, for example, in connection with the command option.

no-X11-forwarding

Forbids X11 forwarding when this key is used for authentication. Any X11 forward requests by the client will return an error.

no-agent-forwarding

Forbids authentication agent forwarding when this key is used for authentication.

no-pty

Prevents tty allocation (a request to allocate a pty will fail).

permitopen="host:port"

Limits local ssh -L port forwarding such that it may connect to only the specified host and port. IPv6 addresses can be specified with an alternative syntax: host/port. Multiple permit open options may be applied separated by commas. No pattern matching is performed on the specified hostnames; they must be literal domains or addresses.


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:

 Key <public_key_filename> 

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:

  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, and so forth), 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 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.

1.

Let's see what files miwa has in his ~/.ssh directory.

 brezup:miwa miwa $ ls -l .ssh ls: .ssh: No such file or directory 

2.

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

 brezup:miwa 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: b3:c9:1f:91:25:ea:31:4d:28:b0:78:34:8a:16:f1:9e miwa@brezup 

3.

To use SSH applications, miwa needs keys. Create his default key as an RSA key of 1024 bits. We enter a passphrase for miwa, but it's not echoed to the screen.

 brezup:miwa miwa $ ls -l .ssh total 16 -rw-------  1 miwa  miwa  951  2 Oct 18:50 id_rsa -rw-r--r--  1 miwa  miwa  221  2 Oct 18:50 id_rsa.pub 

4.

And in his ~/.ssh directory, there are now two files, containing the private and public keypair for his default identity.

brezup:miwa miwa $ slogin ryoko.biosci.ohio-state.edu The authenticity of host 'ryoko.biosci.ohio-state.edu (140.254.104.240)' can't be established. DSA key fingerprint is 17:07:3d:f6:44:55:7d:8a:a2:00:89:b7:76:43:ad:f4. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'ryoko.biosci.ohio-state.edu, 140.254.104.240' (DSA) to the list of known hosts. miwa@ryoko.biosci.ohio-state.edu's password: Last login: Mon Feb 17 2003 19:15:54 -0500 from cvl232015.columb You have new 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 in to 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 only accepting 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.

 brezup:miwa miwa $ cd .ssh brezup:miwa .ssh $ ls -l total 24 -rw-------  1 miwa  miwa  951  2 Oct 18:50 id_rsa -rw-r--r--  1 miwa  miwa  221  2 Oct 18:50 id_rsa.pub -rw-r--r--  1 miwa  miwa  633  2 Oct 18:56 known_hosts brezup:miwa .ssh $ ssh-keygen -e -f id_rsa ---- BEGIN SSH2 PUBLIC KEY ---- Comment: "1024-bit RSA, converted from OpenSSH by miwa@brezup" AAAAB3NzaC1yc2EAAAABIwAAAIEAv09dKFr46dK+U43m8h9hV0JtooRdyf8hbPJcf1y+kX cpcOpHWz7NBqGI3FsZZUrJDrgP3Q/1VHa8SiDsCkYFuG55HobfNfrsGVvW7LqHn9ApzYhi fPUGpLSQnML4/qzTLNn2JmUiEvlcdYrnZoi+b23Om4mLu1zez7nT91EGTnk= ---- 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 can not only generate keys, 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.

 brezup:miwa .ssh $ ssh-keygen -e -f id_rsa > home_rsa.ietf brezup:miwa .ssh $ ls -l total 32 -rw-r--r--  1 miwa  miwa  328  2 Oct 19:05 home_rsa.ietf -rw-------  1 miwa  miwa  951  2 Oct 18:50 id_rsa -rw-r--r--  1 miwa  miwa  221  2 Oct 18:50 id_rsa.pub -rw-r--r--  1 miwa  miwa  633  2 Oct 18:56 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.

 brezup:miwa .ssh $ 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 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.

 brezup:miwa .ssh $ slogin ryoko.biosci.ohio-state.edu miwa@ryoko.biosci.ohio-state.edu's password: Last login: Thu Oct 02 2003 17:56:28 -0500 from dhcp065-024-074- You have new mail. ryoko miwa 1 >ls -l .ssh2 total 2 -rw-r--r--   1 miwa     class        328 Oct  2 19:07 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 cats 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 Oct  2 19:10 authorization -rw-r--r--   1 miwa     class        328 Oct  2 19:07 home_rsa.ietf ryoko .ssh2 5 >chmod 600 authorization home_rsa.ietf ryoko .ssh2 6 >ls -l total 4 -rw-------   1 miwa     class         18 Oct  2 19:10 authorization -rw-------   1 miwa     class        328 Oct  2 19:07 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 through it's a public key and theoretically can't be usefully abused, miwa chmods both files in his .ssh2 directory so that only he can read them, just to be sure.

 brezup:miwa .ssh $ slogin ryoko.biosci.ohio-state.edu Enter passphrase for key '/Users/miwa/.ssh/id_rsa': Last login: Thu Oct 02 2003 18:08:34 -0500 from dhcp065-024-074- You have new mail. ryoko miwa 1 >exit Connection to ryoko.biosci.ohio-state.edu closed. 

11.

Back on brezup, miwa can now slogin to ryoko, and be asked for a passphrase instead of for his considerably weaker password.

 brezup:miwa .ssh $ 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: d4:b9:f7:7a:1f:49:96:b4:9d:ac:1a:3a:5d:0a:57:3b miwa@brezup 

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 only giving out the passphrase 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.

 brezup:miwa .ssh $ ls -l total 48 -rw-r--r--  1 miwa  miwa  328  2 Oct 19:05 home_rsa.ietf -rw-------  1 miwa  miwa  951  2 Oct 18:50 id_rsa -rw-r--r--  1 miwa  miwa  221  2 Oct 18:50 id_rsa.pub -rw-------  1 miwa  miwa  951  2 Oct 19:27 internal_rsa -rw-r--r--  1 miwa  miwa  221  2 Oct 19:27 internal_rsa.pub -rw-r--r--  1 miwa  miwa  633  2 Oct 18:56 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 in the internal_rsa keypair to any of our 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.

 brezup:miwa .ssh $ 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.

 brezup:miwa .ssh $ ls -l total 48 -rw-r--r--  1 miwa  miwa  328  2 Oct 19:05 home_rsa.ietf -rw-------  1 miwa  miwa  951  2 Oct 18:50 id_rsa -rw-r--r--  1 miwa  miwa  221  2 Oct 18:50 id_rsa.pub -rw-------  1 miwa  miwa  951  2 Oct 19:27 internal_rsa -rw-r--r--  1 miwa  miwa  221  2 Oct 19:27 internal_rsa.pub -rw-r--r--  1 miwa  miwa  856  2 Oct 19:31 known_hosts 

15.

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

 brezup:miwa .ssh $ scp internal_rsa.pub.miwa@192.168.1.200:.ssh/miwa_brezup_rsa.pub miwa@192.168.1.200's password: internal_rsa.pub     100% |****************************|   240       00:00 brezup:miwa .ssh $ 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 Oct  2 19:33 authorized_keys -rw-r--r--  1 miwa  staff  221 Oct  2 19:51 miwa_brezup_rsa.pub [creampuf:~/.ssh] miwa% cat miwa_brezup_rsa.pub >> authorized_keys [creampuf:~/.ssh] miwa% cat authorized_keys ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAzc9VaVwZEG8lWJ5SO/t1LfCpZK7dHGbz uTnLXdN2sTLd09EiO567vLHSxRmDddGej79ShvqKh+4EXXZsCjwvuIyJsQvW61FC/IQJ HkCJjCxxmrEaxphPEG5Iu5M2k5JsshmoLL89aKYWYadv1vsBLZ5PxgDTtGE2h+pd8PBa q/0= miwa@brezup [creampuf:~/.ssh] miwa% chmod 600 miwa_brezup_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 what host it will allow them access from. 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 our internal network. Keeping a copy of each of them named in terms of who it allows access, and from which machine, gives him the ability 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 chmods it to owner read/write only, again, just to be safe.

 brezup:miwa .ssh $ cd ~ brezup:miwa miwa $ slogin 192.168.1.200 miwa@192.168.1.200's password: ^C 

17.

Back on brezup, 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 understand maybe 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.

 brezup:miwa 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?

brezup:miwa 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 Oct 2 21:40:08 creampuf xinetd[283]: START: ssh pid=558 from=192.168.1.119. Oct 2 21:40:08 creampuf sshd[618]: Authentication refused: bad ownership or modes for directory /Users/miwa Oct 2 21:40:08 creampuf sshd[618]: Accepted password for miwa from 192.168.1.119 port 49656 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, as 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  29 miwa  staff  986 Oct  2 19:33 /Users/miwa/ 

The problem is that miwa has been being 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 that user 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:~] miwa% ls -ld /Users/miwa/ drwxr-xr-x  29 miwa  staff  986 Oct  2 19:33 /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.

 brezup:miwa 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 login 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.

 brezup:miwa miwa $ ssh-agent SSH_AUTH_SOCK=/tmp/ssh-kyJ6HQ6T/agent.6989; export SSH_AUTH_SOCK; SSH_AGENT_PID=6990; export SSH_AGENT_PID; echo Agent pid 6990; 

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 commands in the syntax of your shell that will set up a shell so that SSH tools run in that shell can find the agent.

In tcsh, the preceding output would be

 setenv SSH_AUTH_SOCK /tmp/ssh-kyJ6HQ6T/agent.6989; setenv SSH_AGENT_PID6990; echo Agent pid 6990; 

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

 brezup:miwa miwa $ SSH_AUTH_SOCK=/tmp/ssh-kyJ6HQ6T/agent.6989; export SSH_AUTH_SOCK; brezup:miwa miwa $ SSH_AGENT_PID=6990; export SSH_AGENT_PID; 

TIP

Instead of copying and pasting the default ssh-agent output, you could just execute ssh-agent at the command line as `ssh-agent` to have that output executed for you.


21.

miwa runs the two commands to set the environment variables, 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.

 brezup:miwa miwa $ ssh-add Enter passphrase for /Users/miwa/.ssh/id_rsa: Identity added: /Users/miwa/.ssh/id_rsa (/Users/miwa/.ssh/id_rsa) brezup:miwa 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 into the remote systems that accept these identities by using slogin.

 brezup:miwa miwa $ ssh-add -L ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAv09dKFr46dK+U43m8h9hV0JtooRdyf8 hbPJcf1y+kXcpcOpHWz7NBqGI3FsZZUrJDrgP3Q/1VHa8SiDsCkYFuG55HobfNfrsGV vW7LqHn9ApzYhifPUGpLSQnML4/qzTLNn2JmUiEvlcdYrnZoi+b23Om4mLu1zez7nT9 1EGTnk= /Users/miwa/.ssh/id_rsa ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAzc9VaVwZEG8lWJ5SO/t1LfCpZK7dHGb z uTnLXdN2sTLd09EiO567vLHSxRmDddGej79ShvqKh+4EXXZsCjwvuIyJsQvW61FC/ IQJ HkCJjCxxmrEaxphPEG5Iu5M2k5JsshmoLL89aKYWYadv1vsBLZ5PxgDTtGE2h+p d8PBaq/0= .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:

 brezup:miwa miwa $ slogin ryoko.biosci.ohio-state.edu Last login: Thu Oct 02 2003 18:24:46 -0500 from dhcp065-024-074- You have new mail. ryoko miwa 1 >exit Connection to ryoko.biosci.ohio-state.edu closed. brezup:miwa 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 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.

Table 21.4. Documentation for ssh-agent

ssh-agent

Authentication agent.

ssh-agent [-a <bind_address>] [-c | -s] [-t <life>] [-d] [<command> [<args> ...]]

ssh-agent [-c | -s] -k

ssh-agent is a program to hold private keys used for public key authentication (RSA, DSA). ssh-agent is started in the beginning of an X-session or a login session, and all other windows or programs are started as clients to the ssh-agent program. Through use of environment variables the agent can be located and automatically used for authentication when logging in to other machines using ssh.

-a <bind_address>

Binds the agent to the unix-domain socket <bind_address>. The default is /tmp/ssh-XXXXXXXX/agent.<ppid>.

-c

Generates C-shell commands on stdout. This is the default if SHELL looks like it's a csh style of shell.

-s

Generates Bourne shell commands on stdout. This is the default if SHELL does not look like it's a csh style of shell.

-k

Kills the current agent (given by the SSH_AGENT_PID environment variable).

-d

Debug mode. When this option is specified ssh-agent does not fork.


Table 21.5. Documentation for ssh-add

ssh-add

Adds RSA or DSA identities to the authentication agent.

ssh-add [-lLdDxXc] [-t <life>] [<file> ...]

ssh-add adds RSA or DSA identities to the authentication agent, ssh-agent(1). When run without arguments, it adds the files $HOME/.ssh/id_rsa, $HOME/.ssh/id_dsa and $HOME/.ssh/identity. Alternative file names can be given on the command line. If any file requires a passphrase, ssh-add asks for the passphrase from the user. The passphrase is read from the user's tty. ssh-add retries the last passphrase if multiple identity files are given.

The authentication agent must be running and must be an ancestor of the current process for ssh-add to work.

-l

Lists fingerprints of all identities currently represented by the agent.

-L

Lists public key parameters of all identities currently represented by the agent.

-d

Deletes the identity from the agent.

-D

Deletes all identities from the agent.

-x

Locks the agent with a password.

-X

Unlocks the agent.

-c

Indicates that added identities should be subject to confirmation before being used for authentication.

-t <life>

Sets a maximum lifetime when adding identities to an agent. The lifetime may be specified in seconds or in a time format specified in sshd.


CAUTION

It should be noted that using ssh-agent in this fashion is, as they say, putting all of your eggs in one basket. If a malicious user could find a way to co-opt the use of your ssh-agent, it would allow him to spoof connections as you, and your ssh-agent would happily provide your credentials to verify their false claim. Properly configured file permissions for keys in your .ssh directory will go a long way towards minimizing this problem. However, if a cracker has actually managed to break in to your account, he can access your key files with your permissions, and a running ssh-agent that you've started will have no way to tell you apart. Should this happen, using ssh-agent does materially weaken your security.

If you only use SSH in a mode where the remote systems require you to enter your passphrase directly out of your brain, a cracker who has broken one of your accounts is no closer to cracking your others. If you use ssh-agent to hold all of your credentials, and the cracker happens along while you've a running copy of ssh-agent that's serving credentials for you, the cracker will have full access to your accounts on machines for which ssh-agent holds credentials.


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:

1.

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

2.

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 of your users, putting it in /Applications/ would be appropriate. Eject the disk image when you're done.

3.

Run the SSH Agent application and open the Preferences panel.

4.

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

Figure 21.4. Setting the SSH Agent application to serve credentials globally.


5.

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

Figure 21.5. Setting environment variables through SSH Agent.


6.

Log out, log back in, and restart SSH Agent.

7.

Open the Preferences panel again, and go to the Default Identities pane.

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.

Windows

A number of Windows SSH clients are available. Among the available clients are

  • Tera Term Pro with TTSSH A free Terminal emulation program available at http://hp.vector.co.jp/authors/VA002416/teraterm.html. A free extension DLL called TTSSH is available for Tera Term at http://www.zip.com.au/~roca/ttssh.html. With the extension, Tera Term can be used as an SSH client. It supports only the SSH1 protocol. Additionally, it can handle public key authentication, tunneling, and X11 forwarding.

  • PuTTY A free Telnet and SSH client available at http://www.chiark.greenend.org.uk/~sgtatham/putty/. PuTTY supports both the SSH1 and SSH2 protocols, with SSH1 being the default protocol. It also supports public key authentication, tunneling, and X11 forwarding. Additionally, it includes scp (PSCP) and sftp (PSFTP) clients.

  • F-Secure SSH A commercial SSH client. It is available for Windows 95/98/Me/NT 4.0/2000/XP/2003. It supports both the SSH1 and SSH2 protocols. It also supports public key authentication, tunneling, and X11 forwarding. Additionally, it includes a built-in sftp client and command-line ssh tools. For more product information, see http://www.wrq.com/products/reflection/ssh/.

  • SSH Secure Shell SSH Communications Security has both a commercial and free SSH client for Windows 95/98/Me/NT 4.0/2000/XP. It supports both the SSH1 and SSH2 protocols. It also supports public key authentication, tunneling, and X11 forwarding. Additionally, it includes a built-in sftp client. For more product information, see http://www.ssh.com/. To download the freely available client, go to ftp://ftp.ssh.com/pub/ssh/ and select the Windows client.

  • SecureCRT A commercial SSH client available from http://www.vandyke.com/products/securecrt/. It supports both the SSH1 and SSH2 protocols. It also supports public key authentication, tunneling, X11 forwarding, and sftp.

Macintosh 8/9

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

  • NiftyTelnet 1.1 SSH r3 A free Telnet and SSH client available at http://www.lysator.liu.se/~jonasw/freeware/niftyssh/. It supports only the SSH1 protocol. It also supports public key authentication and has a built-in scp function.

  • MacSSH A free client for SSH, Telnet, and various other protocols available at http://www.macssh.com/. For SSH, it supports only the SSH2 protocol. Additionally, it supports public key authentication, tunneling, and X11 forwarding.

  • MacSFTP A shareware sftp client available at http://www.macssh.com/. It supports both SSH1 and SSH2. You can download a 15-day trial. If you decide to keep it, the shareware cost is $25. It has an interface similar to Fetch's.

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

  • JellyfiSSH A freeware product available from http://www.arenasoftware.com/grepsoft/. It provides a GUI login interface and bookmarking capabilities. After you've entered your login information, it brings up a Terminal window to the remote host, showing the command that was issued. If you are comfortable with using slogin or ssh to log in to a remote host, this application might not be useful to you. If you like the basic GUI login interface of the clients for traditional Mac OS, this application might be useful to you. If you want to learn how to use the ssh command-line client, this application might be useful to you because you can see how the command was issued.

  • Terminal.app As of Mac OS X 10.3, Terminal.app's Connect to Server option under the File menu offers a graphical interface to the ssh and sftp commands. Enter the information in the graphical interface, and a terminal opens up running the command. If you are comfortable with the basic command-line ssh and sftp, this interface might not interest you. Otherwise, you might find it useful for learning how to issue the commands.

  • Fugu A freeware product available from http://rsug.itd.umich.edu/software/fugu/. It is an scp/sftp/ssh tunneling client.

  • SSH Tunnel Manager A freeware product available from http://projects.tynsoe.org/en/stm/. As the name suggests, this is a graphical application that helps you set up and manage your SSH tunnels.

  • MacSFTP Also works in Mac OS X. This shareware sftp client is available at http://www.macssh.com/. It supports both the SSH1 and SSH2 protocols. You can download a 15-day trial. If you decide you like it, the shareware cost is $25. It has an interface similar to Fetch's.

  • Gideon A shareware sftp/ftp client available at http://www.gideonsoftworks.com/gideon.html. The shareware cost is $25, payable if you like it.

  • RBrowser An application available from http://www.rbrowser.com/. It provides a finder interface to ssh, scp, and sftp, and also supports tunneling. If you do not like the command line at all, this might be the application for you. The sftp feature works by dragging files from one "finder" to the other. This is a shareware product with two levels of licensing: a basic level that covers ftp and sftp features and a professional level that includes ftp, sftp, Unix, ssh, and ssh tunneling. Demo licenses are also available.

  • SSH Agent A graphical manager for ssh-agent. SSH Agent is freely available from http://www.phil.uu.nl/~xges/ssh/.

  • SSHKeychain A graphical manager for ssh-agent. This package is freely available from http://www.sshkeychain.org/. It also includes Apple Keychain support.

     < Day Day Up > 


    Mac OS X Tiger Unleashed
    Mac OS X Tiger Unleashed
    ISBN: 0672327465
    EAN: 2147483647
    Year: 2005
    Pages: 251

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net