Accessing Mac OS X Remotely Using Apple Remote Desktop
| < Day Day Up > |
Running Shells and Commands Remotely Using SSHWith 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
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
There is also an SSH
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 ServerIf 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
Working with SSH UtilitiesThe 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
Making Terminal Connections with
ssh
/
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
.ohio-state.edu:110 -N -L 2125:rosalyn.biosci.ohio-state.edu:25
|
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
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
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
|
|
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
<
|
|
|
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
|
|
-e |
Reads a private or public OpenSSH key file and prints the key in a SECSH Public Key File Format to
|
|
-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 |
|
|
-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
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
|
|
environment=" NAME=value " |
Specifies that the string is to be added to the environment when logging in using this key. Environment
|
|
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. |
{% if main.adsdop %}{% include 'adsenceinline.tpl' %}{% endif %}
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
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
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
If you're dealing with SSH on a daily basis, using
ssh-agent
is almost
-
Start the ssh-agent .
-
Set up your environment so that SSH applications can find the agent.
-
Add identities to the agent.
-
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
|
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
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 |
|
|
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
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
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 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 chmod
s 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
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 (
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
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
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
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 Although it doesn't show up in print, there was actually a
[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 [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
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
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.
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;
|
|
|
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.
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
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
The authentication agent must be running and must be an
|
|
|
-l |
Lists
|
|
-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,
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
|
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
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
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 > |
Similar products
- Microsoft Windows XP Professional Administrator's Guide
What reasons should i be caucious while using windows task manager - Microsoft Visual Basic 2005 Express Edition Programming for the Absolute Beginner
Dictionary layout made from visual basic - JUNOS Cookbook
How to disable secure ftp junos - Access Cookbook
How to save data in form in frontpage on local host?