Mac OS X Unleashed

Mac OS X Unleashed

By John Ray and William C. Ray

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. Then the user transfers the public key to the remote host to which she would like to connect. So, the remote host stores a set of public keys for machines on which you have generated a key-pair and transferred a copy of your public key. Furthermore, you can protect your key with a passphrase, rather than a password.

The procedure for enabling public-key authentication is similar in SSH1 and SSH2. We will concentrate our efforts on transferring keys between Mac OS machines and Unix machines. We will also demonstrate generating key-pairs on the Unix side. Finally, we will demonstrate key authentication between Unix machines.

Public Key Authentication in SSH2

In this section, we will demonstrate how to enable public key authentication for two types of SSH2 servers. The difference between types of SSH2 servers is most apparent in how public key authentication is done. We will first look at public-key authentication between a Mac OS machine and an OS X machine. Then we will demonstrate how to enable public key authentication between a Mac OS machine and a Unix machine running an SSH2 server based on a non-OpenSSH package.

Authentication Between a Mac OS Machine and an OS X Machine

It is easiest to start the process of enabling public key authentication on the OS X machine. In particular, starting with the OS X machine provides an opportunity to more quickly see what the F-Secure client will do on your Mac OS machine. It also starts to prepare the user on the OS X machine to be able to connect from the OS X machine to other machines via public key authentication. To set up public key authentication, perform these steps, substituting your user ID and machine information as appropriate:

  1. On your OS X machine, generate a key-pair by running 
    ssh-keygen -d -C <username>@<osx-hostname>
    The -d option specifies DSA authentication, which is the default encryption mode for SSH2. The -C specifies what kind of comment to make. In other versions of ssh-keygen, the comment is typically of the form <use r name> @ <hostname> . Sometimes comments contain more information. On the OS X machine where the sample was run, ssh-keygen generates a comment of <user> @ <localhost> , without specifying a more specific comment. When you run ssh-keygen, you are asked for a passphrase to protect the private key. It is recommended that the passphrase be at least 11 characters long and include as many character types as possible: uppercase letters, lowercase letters, numbers, and special characters. Spaces may be included as part of the passphrase. Here is a sample run: 
    [localhost:~] miwa% ssh-keygen -d -C miwa@ryoohki

     Generating DSA parameter and key.
     Enter file in which to save the key (/Users/miwa/.ssh/id_dsa): Enter passphrase 

            ccc.gif
         (empty for no passphrase):
     Enter same passphrase again:
     Your identification has been saved in /Users/miwa/.ssh/id_dsa.
     Your public key has been saved in /Users/miwa/.ssh/id_dsa.pub.
     The key fingerprint is:
     54:ae:7a:73:2e:12:3b:2e:68:ce:8d:61:33:95:83:81 miwa@ryoohki
    As ssh-keygen tells us, user miwa does indeed have the promised keys, as shown below. The private key was saved as id_dsa, and the public key was saved as id_dsa.pub, both are stored in the directory ~/.ssh/. 
    [localhost:~/.ssh] miwa% ls -al

     total 32
     drwx------   6 miwa  staff   160 Apr 16 16:55 .
     drwxr-xr-x  15 miwa  staff   466 Apr 16 15:46 ..
     -rw-------   1 miwa  staff   736 Apr 16 16:56 id_dsa
     -rw-r--r--   1 miwa  staff   602 Apr 16 16:56 id_dsa.pub
     -rw-r--r--   1 miwa  staff   353 Apr 16 15:31 known_hosts
     -rw-------   1 miwa  staff  1024 Apr 16 16:56 prng_seed
  2. In the .ssh directory on your OS X machine, copy id_dsa.pub to autho r ized_keys2: 
    [localhost:~/.ssh] miwa% cp id_dsa.pub authorized_keys2
    The file authorized_keys2 is where your OS X machine stores the SSH2 public keys of authorized hosts. Anyone who has the matching private key for a given public key in this file is authorized to connect to this host as this user.
  3. Test that your passphrase works if you connect to your OS X machine from your OS X machine. The -2 option forces ssh to use the SSH2 protocol. 
    [localhost:~] miwa% ssh -2 ryoohki

     The authenticity of host 'ryoohki' can't be established.
     DSA key fingerprint is e8:3f:30:28:ca:ac:f0:92:05:ab:95:2d:59:80:67:bd.
     Are you sure you want to continue connecting (yes/no)? yes
     Warning: Permanently added 'ryoohki,140.254.12.124' (DSA) to the list of known hosts.
     Enter passphrase for DSA key '/Users/miwa/.ssh/id_dsa':
     Welcome to Darwin!

[localhost:~] miwa% exit

     logout
     Connection to ryoohki closed.
  4. On the Mac OS machine, connect to the OS X machine using your saved desktop alias.
  5. Select Create Public Key under the File menu. The Public Key Authentication Key Generator dialog box appears, as shown in Figure 26.30.
    26fig30.gif

    Figure 26.30 Indicate parameters for public key generation in the Public Key Authentication Key Generator dialog.

  6. In the Public Key Authentication Key Generator dialog box, enter a comment in the comment field. A comment of the form <user> @ <macos-host> would follow the default comment form when a key is generated on a Unix machine.
  7. Make sure that DSA is selected. DSA is the default encryption for SSH2. RSA encryption is an option, and therefore not present in all versions of SSH2. DSA is already selected here by default.
  8. Enter a length of no less than 1024 bits and no longer than 2048 bits. 1024 is the default.
  9. Enter a passphrase to encrypt the private key. Again, it is recommended that the passphrase be at least 11 characters long and include as many character types as possible: uppercase letters, lowercase letters, numbers, and special characters. Spaces may be included as part of the passphrase.
  10. Select a clipboard option. The Copy Install Script option copies a script to the clipboard for transferring the public key to the server. Although it is probably all right to use this option, we avoid this as a precaution. The Copy Public Key option copies only the contents of the public key to the clipboard. We recommend this option. The Leave alone option does nothing.
  11. Click on Create New Key Pair.
  12. Save the public key and private key. Do not add an extension to the private key, and do not change the .pub extension of the public key. The filenames default to key and key.pub. If multiple users use the Mac OS machine, it is recommended that, for easy sorting, each user store his keys in his own folder in the F-Secure SSH folder.
  13. In the OS X terminal window connection, create a file in your .ssh directory with a name that lets you know which host this public key belongs to and that you created it in the SSH2 client. You might consider something of the form <m a cos-host> -ssh2.pub. The public key that was created in F-Secure SSH has this form: 
    ---- BEGIN SSH2 PUBLIC KEY ----
Comment: "miwa@hobbes"
AAAAB3NzaC1kc3MAAACBALPMiCqdPDGxcyB1IwPrPXk3oEqvpxR62EsspxGKGGbOM6mf60
i1hwTvjZzDhUSR7ViGeCopKtjJIqn2ljgeLbhFsQUX2UyJ6A1cFVuef0x6GVAsybqbtJc8
JBh41U+iSXJKppEY5BI+REMydpBXJf2qT/8yZeq3NPjiOiMb6TyjAAAAFQDYvvV4WQK1Zu
23q/7iLKg5j/zi5wAAAIBR7vgrQpjKW2cprIUJsnenTm4hnBrEO7NMUomjgezrY23iZdIS
QlU1ESMgx9W9nnZstd2vjeqHDSmmcD2p/aGqhl3N1WlYk8zgFYYJilPwRxVm77Np/vXz/M
QpygJE7ToXGvfHqVmdBpUyakyfx6DveWhFPis1Ab8N1RCPWm6PMwAAAIAytHjAAMYscqX2
tl4icw3oOku3HIvoHBCx9D6Q9LjCqt7DqqgMN2e5vuvNz0hzqBaBDJsjNA/A4bI88ZrgLh
fJM/Nhs2xkcb7AYeHEtuGKVbsbB0EjsECtLRHydfmk3wDQjUVT92HsodFvsIl4Je7seWUu
iAEe0V1xfF7XrXuwNQ==
---- END SSH2 PUBLIC KEY ----
    This form is not quite compatible with the form that the OpenSSH package uses. The form that is acceptable for OpenSSH's SSH2 public key is 
    ssh-dss lots-of-characters== comment
    The form for SSH2 in OpenSSH is contained on one line. On the OS X machine, you can run an option to ssh-keygen that converts the format created in F-Secure to an OpenSSH-compatible format. Use 
    ssh-keygen -X -f <macos-host>-ssh2.pub > <macos-host>-ssh2-open.pub
    The preceding statement converts the SSH2-format public key to an OpenSSH format public key and outputs it to a file called <macos-host> -ssh2.pub. Here is a sample of what the command does: 
    [localhost:~/.ssh] miwa% ssh-keygen -X -f hobbes-ssh2.pub > hobbes-ssh2-open.pub

ignore: ---- BEGIN SSH2 PUBLIC KEY ----
ignore: Comment: "miwa@hobbes"
ignore: ---- END SSH2 PUBLIC KEY ----
    We see some output on ignoring some lines, but it creates hobbes-ssh2-open.pub in OpenSSH format. You can also use a text editor to edit the public key file that you created so that it has the appropriate form. Before you edit the file, even if you are using an editor that makes a backup file, make a backup copy. The OpenSSH format is also not difficult to create in an editor.
  14. Add the public key from your Mac OS machine to the authorized_keys2 file in your .ssh directory on the OS X host. Before you edit the autho r ized_keys2 file, make a backup copy. As you might recall, the first key in the authorized_keys2 file is the public key that you generated on your OS X machine. Add a blank line after that key, and then add a copy of the public key from your Mac OS machine that you modified to fit the form of the autho r ized_keys2 file. For our user miwa, the authorization_keys2 file looks like this: 
    [localhost:~/.ssh] miwa% more authorized_keys2

ssh-dssAAAAB3NzaC1kc3MAAACBALzT9RbceziStHPmMiHmg78hXUgcMP14sJZ/7MH/p2NX/fB0cmbU
LPNgEN8jrs8w9N73J7yUFHSPR/LVfBj+UwkIzwjyXUW/z/VmCs25IDF/UBn1OQK5PCi16rF0F+Cx0hMN
4R3AaFAetXBdLqoom5x4Yo9gdspPqhhB44QnT43JAAAAFQDWTkKDJ2m4SApHZ/qRnRpMN5whTQAAAIAV
ADOsHpnUdUOFKjIgxZ0Hwh7IaMQ2ofG/6PmbmNG/8zXRdxmu/JrBzieWHq6sSRSkWDSDIjuEuTkZyJ4w
x3KsLmhIrtlBw3NCcsJT2GfGQ9gEBm8fkUpeQyKAQcirbx4Hw93iMFC3g9A8cwqmA4DalKSX3un7cweN
U32Irhq+gAAAIAz+lDSjqjFzuTV4vJ/P83nH2uwb62/iCSIB9cL32hrOm234imaAceu8pN9qqEAPr9Ai
lCWa+lqGvgcdyDK0vZTvKQnk6KOU3TJfDyMR7i/gzW4P4TA/k/+YbognMCZ7SWYQXhZXWBhiPObVLYPf
fDJsLdpkyBXjZbx+Zmrmi4Bxg== miwa@ryoohki

ssh-dss AAAAB3NzaC1kc3MAAACBALPMiCqdPDGxcyB1IwPrPXk3oEqvpxR62EsspxGKGGbOM6mf60i1h
wTvjZzDhUSR7ViGeCopKtjJIqn2ljgeLbhFsQUX2UyJ6A1cFVuef0x6GVAsybqbtJc8JBh41U+iSXJKpp
EY5BI+REMydpBXJf2qT/8yZeq3NPjiOiMb6TyjAAAAFQDYvvV4WQK1Zu23q/7iLKg5j/zi5wAAAIBR7vg
rQpjKW2cprIUJsnenTm4hnBrEO7NMUomjgezrY23iZdISQlU1ESMgx9W9nnZstd2vjeqHDSmmcD2p/aGq
hl3N1WlYk8zgFYYJilPwRxVm77Np/vXz/MQpygJE7ToXGvfHqVmdBpUyakyfx6DveWhFPis1Ab8N1RCPW
m6PMwAAAIAytHjAAMYscqX2tl4icw3oOku3HIvoHBCx9D6Q9LjCqt7DqqgMN2e5vuvNz0hzqBaBDJsjNA
/A4bI88ZrgLhfJM/Nhs2xkcb7AYeHEtuGKVbsbB0EjsECtLRHydfmk3wDQjUVT92HsodFvsIl4Je7seWU
uiAEe0V1xfF7XrXuwNQ== miwa@hobbes
    Although this looks like several lines, it is really a three-line file. Line 1 contains the public key for the OS X machine. Line 2 is blank. Line 3 contains the public key for the Mac OS machine.
  15. Log out of the OS X machine.
  16. Start another connection to your OS X machine in F-Secure SSH 2.1. So that you have the option to connect via public key authentication, do not use your desktop alias to make this connection.
  17. In the Connect section of the Properties dialog box, shown in Figure 26.31, enter your OS X machine as the SSH server. Select Public Key and then select your private key file by clicking the Select button and navigate the file system to your key file, as shown in Figure 26.32. Click Connect.
    26fig31.jpg

    Figure 26.31 You can choose to connect via public key authentication or password authentication in the Connect section of the Properties dialog.

    26fig32.jpg

    Figure 26.32 Find the private key file you created by browsing your system in the file dialog.

  18. After a connection with the remote machine has been established, you will be prompted for your passphrase as shown in Figure 26.33. Enter the passphrase for the public key that you created on your Mac OS machine and click OK.
    26fig33.jpg

    Figure 26.33 Enter the pass-phrase for the public key created on the Mac OS machine to complete the login procedure.

If all went well, you are now connected to your OS X machine. If you end up having to connect via password instead, the public key for the Mac OS machine in your authorized_keys2 might not yet be in the right form. Make sure that you have removed any spaces and returns that have been in the original public key file, without altering any of the characters in the long string. If all else fails, start over from scratch.

If you would like to connect to your OS X machine from your Mac OS machine by regularly using a passphrase, be sure to save these new settings, or an alias to them, to your desktop. You can also modify your tunnel connections so that you connect via public key authentication. Unfortunately, you still have to use a password in the FTP or e-mail client.

Authentication Between a Mac OS Machine and a Unix Machine Running a Separate SSH2 Server

Believe it or not, you have already completed the complicated part. The remote host we will use in this section is running an SSH2 server that comes from the SSH Communications Security/F-Secure product line. Some of the commands you will run are slightly different than in the previous section, and the keys are stored differently than in the previous section. However, because you might have to connect to SSH2 servers running this product line, it is useful to see a different demonstration of enabling public key authentication.

Again, it is easiest to start the process of enabling public key authentication on the Unix machine. In particular, this provides an opportunity to see, more quickly, what the F-Secure client will do on your Mac OS machine. It also starts to prepare the user on the Unix machine to be able to connect from the Unix machine to other machines via public key authentication. To do this, follow these steps:

  1. On the remote host, generate a key-pair by running 
    ssh-keygen
    On systems like this one, the ssh commands default to the SSH2 protocol. However, if you want to be certain that you are invoking an SSH2 protocol, append 2 to the end of the command. In this example, you could specify ssh-keygen2 to be absolutely certain that you are specifying the desired protocol. As was the case on the OS X machine, when you run ssh-keygen you are asked for a passphrase to protect the key. Follow the same guidelines as you used on the OS X machine. Make sure that the passphrase is at least 11 characters long and includes a variety of characters. Here is a sample run: 
    Rosalyn miwa 69 >ssh-keygen

     Generating 1024-bit dsa key pair
        2 oOo.oOo.oOo.
     Key generated.
     1024-bit dsa, miwa@Rosalyn, Mon Apr 16 2001 17:23:31
     Passphrase :
     Again      :
     Private key saved to /home/miwa/.ssh2/id_dsa_1024_a
     Public key saved to /home/miwa/.ssh2/id_dsa_1024_a.pub
    Just as you saw on our OS X machine, ssh-keygen has generated a private key and a public key. On this system, the private key is called id_dsa_1024_a, and the public key is called id_dsa_1024_a.pub. On our OS X machine, the keys are stored in a directory called .ssh. On this system, they are stored in a directory called .ssh2. If we check the results of our run, we do indeed see that the keys have been generated and stored as ssh-keygen specified they would: 
    Rosalyn .ssh2 71 >ls -al

     total 12
     drwxr-xr-x   3 miwa     class        512 Apr 16  2001 .
     drwxr-xr-x  14 miwa     class       1024 Apr 16 11:55 ..
     drwx------   2 miwa     class        512 Apr 13 16:12 hostkeys
     -rw-------   1 miwa     class        868 Apr 16  2001 id_dsa_1024_a
     -rw-r--r--   1 miwa     class        729 Apr 16  2001 id_dsa_1024_a.pub
     -rw-------   1 miwa     class        512 Apr 16  2001 random_seed
  2. In the .ssh2 directory on the remote host, create a file called identification, whose contents are this line: 
    IdKey id_dsa_1024_a
    This file identifies which key is your private key.
  3. In the .ssh2 directory on the remote host, create a file called authorization, whose contents are this line: 
    Key id_dsa_1024_a.pub
    The K must be capitalized. The file authorization is where the remote host stores the listing of SSH2 public keys for authorized hosts. Anyone who has the matching private key for a given public key in this file is authorized to connect to this host as user miwa. As you might recall, on the OS X machine, the file that stores this information is a u thorized_keys2.
  4. Test that your passphrase works if you connect to the remote host from the remote host. Again, on this system, the ssh commands default to the SSH2 protocol. To be more specific, you could also use ssh2 instead of ssh. 
    Rosalyn miwa 4 >ssh rosalyn

     Passphrase for key "/home/miwa/.ssh2/id_dsa_1024_a" with comment "1024-bit dsa,

            ccc.gif
          miwa@Rosalyn, Mon Apr 16 2001 17:23:31":
     Last login: Mon Apr 16 2001 17:20:56 from
     You have mail.
     You have mail.

Rosalyn miwa 1 >exit
  5. End your terminal session with the remote host. Assuming that you are connecting to this remote host from the same Mac OS machine that you used for connecting to the OS X host in the previous section, you have already created your key-pair for this machine. If you are using a different Mac OS machine, follow the steps in the previous section for creating your key-pair.
  6. Now transfer a copy of your public key (if you saved by the default name, this is key.pub) to the remote host. Use your ingenuity to make this happen. As you might recall, we recommended that you paste this key into a file called something like <macos-host> -ssh2.pub in your .ssh directory on your OS X machine. One reason we suggested this was to make it easier to edit the public key into an acceptable form for OpenSSH. The other reason we suggested it was to make it easier for you to transfer the key to other remote Unix hosts. With the key already on your OS X machine, you can now scp or sftp the key to the other remote Unix host with the knowledge that nothing odd happened. Copying these keys in Mac OS can sometimes be frustrating. Of course, if the remote host is running an FTP server, you could certainly ftp the key from your Mac OS machine through an SSH tunnel to the remote host. At any rate, choose a method you are comfortable with to transfer the public key to this remote host. Whatever method you choose, make sure that nothing about the formatting changes. We know this to be the case using the scp/sftp method. After transferring his Mac OS machine's public key, user miwa's .ssh2 directory looks like this: 
    Rosalyn .ssh2 81 >ls -al

     total 18
     drwxr-xr-x   3 miwa     class        512 Apr 16  2001 .
     drwxr-xr-x  14 miwa     class        512 Apr 16 13:39 ..
     -rw-------   1 miwa     class         15 Apr 16  2001 authorization
     -rw-------   1 miwa     class        675 Apr 16 13:56 hobbes.pub
     drwx------   2 miwa     class        512 Apr 13 16:12 hostkeys
     -rw-------   1 miwa     class        868 Apr 16 13:32 id_dsa_1024_a
     -rw-r--r--   1 miwa     class        729 Apr 16 13:32 id_dsa_1024_a.pub
     -rw-r--r--   1 miwa     class         20 Apr 16 13:38 identification
     -rw-------   1 miwa     class        512 Apr 16 13:32 random_seed
  7. On the remote host, make a backup copy of the authorization file. Remember, this is the file the host uses to identify authorized public keys.
  8. Edit the file authorization. Add a line that points to the file that contains the public key for your Mac OS machine. In our example, user miwa's authorization file looks like this: 
    Key id_dsa_1024_a.pub
Key hobbes.pub
  9. End the terminal session.
  10. Start a new terminal session. Do not start the terminal session from your already existing desktop alias.
  11. In the Connect section of the Properties dialog box, enter your OS X machine as the SSH server. Select Public Key and then select your private key file. Click Connect.
  12. Enter the passphrase for the public key that you created on your Mac OS machine and click OK.

If all went well, you are now connected to the remote host. If you have to connect via password instead, check whether the authorization file points to the right file. Check to see that the file it points to is of the accepted format. Remember, that an acceptable format looks like this:

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "<user>@<macos-host>"
String-of-characters-70-characters-wide-with-returns-at-each-line==
---- END SSH2 PUBLIC KEY ----

If all else fails, start over from scratch.

If you would like to connect to this remote host from your Mac OS machine by regularly using a passphrase, be sure to save these new settings to your desktop. You can also modify your tunnel connections so that you connect via public key authentication. Unfortunately, you still have to use a password in the FTP or e-mail client.

Public Key Authentication Between an OS X Machine and Another Unix Host

In this section, we will demonstrate enabling public key authentication between an OS X machine and a Unix machine running a non-OpenSSH style SSH2 server. Based on the previous two sections, you are probably formulating ideas on how you might do this.

If we skip the little details on dealing with the Mac OS client, what we did in the other sections can be summarized as follows:

  1. Create keys on host A, which you would like to use for remotely accessing host B.
  2. Transfer a copy of the public key that was just created on host A to the remote host B.
  3. Make the remote host B aware that it has a copy of a public key from host A.
  4. Log in to host B from host A using a passphrase. Your private key from host A and your public key from host A together authenticate the login. In practice, this means that your host A private key (stored on host A) combined with the copy of your host A public key (stored on host B) authenticates your login to host B from host A.

How does this translate to public key authentication between an OS X machine and another Unix host? In the examples carried out in this chapter thus far, we already generated private and public keys on our OS X machine using ssh-keygen -d. We also already created public and private keys on our remote Unix host by running ssh-keygen (or ssh-keygen2). So, we are already part of the way there! Next, we need to format our public keys appropriately for the different types of SSH2 servers and then transfer our public keys between the hosts. We could, of course, skip the formatting step if we were attempting public key authentication between machines running the same type of SSH2 server. But before we continue further, we will outline the procedure from start to finish.

  1. On the OS X machine:
    • Generate public and private keys by running: 
      ssh-keygen -d -C <username>@<osx-hostname>
    • Create the file that holds the set of authorized public keys: 
      cp .ssh/id_dsa.pub .ssh/authorized_keys2
    • Test that the passphrase works by connecting from the OS X Make a backup copy of your public key. Name it something that is easily identifiable to you when you are on a remote host. If given a good name, the backup copy is probably the most informative copy to transfer to other hosts. 
      cp .ssh/id_dsa.pub .ssh/<this-osx-host>-ssh2.pub
    • Make a copy of the file that is in a form acceptable to other SSH2 servers. Remember that this is the basic form: 
      ---- BEGIN SSH2 PUBLIC KEY ----
Comment: "<user>@<osx-host>"
String-of-characters-70-characters-wide-with-returns-at-each-line==
---- END SSH2 PUBLIC KEY ----

You can make your public key in an acceptable format for other machines by manually editing the file to the form above, or by running an ssh-keygen command that does it for you:

ssh-keygen -x -f id_dsa.pub > <this-osx-host>-ssh2-ssh2.pub

With the -x, this ssh-keygen command converts an OpenSSH format private key to an SSH2-format public key, and then outputs it to a file named <this-osx-host>-ssh2-ssh2.pub. You can use any filenames you want.

Here is an example:

[localhost:~/.ssh] miwa% ssh-keygen -x -f id_dsa > ryoohki-ssh2-ssh2.pub

     Enter passphrase:

If we look at the first couple of lines of the file, we see that the comment includes <user> @ <localhost> . You might want to change that comment to something more informative to you, such as <user> @ <hostname> .

[localhost:~/.ssh] miwa% more ryoohki-ssh2-ssh2.pub

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "1024-bit DSA, converted from OpenSSH by miwa@localhost"

You can also edit the public key file in an editor. If you do, be sure to remember that the length of the lines is 70 characters.

[localhost:~/.ssh] miwa% scp ryoohki-ssh2.pub rosalyn:.ssh2/ryoohki.pub

     miwa@rosalyn's password:
     warning: Executing scp1 compatibility.
     ryoohki-ssh2.pub     100% |*****************************|   677       00:00
  1. On the remote Unix host:
    • Generate public and private keys by running: 
      ssh-keygen2
    • Create .ssh2/identification, whose content is this line: 
      IdKey id_dsa_1024_a.pub
    • Create .ssh2/authorization, whose content is this line: 
      Key id_dsa_1024_a.pub
    • Test that the passphrase works by connecting from the Unix host to the Unix host
    • Make a backup copy of the public key 
      cp .ssh2/id_dsa_1024_a.pub <remote-host>.pub
      If you feel comfortable with your editor, create a copy of the public key so that it is in OpenSSH format. This format is easy to create in an editor. Remember that this is the basic form, all on one line: 
      ssh-dsa Lots of characters== <user>@<remote-host>

If you don't feel comfortable doing that in your editor, wait until you have transferred the file to the OS X machine so that you can convert formats.

Transfer a copy of the public key to the OS X machine. Again, use whatever name is useful to you. Here is what our user miwa did to transfer his public key:

Rosalyn .ssh2 9 >scp rosalyn-ssh2.pub ryoohki:.ssh/rosalyn.pub

     miwa@ryoohki's password:
     Transfering rosalyn-ssh2.pub -> ryoohki:.ssh/rosalyn.pub  (1k)
     |.............................................................................|
602 bytes transferred in 0.06 seconds [9.68 kB/sec].

As you might recall, the above command converts the remote host's SSH2-format public key to an OpenSSH format public key and outputs that to the file <remote-host> -ssh2-open.pub. Remember, you can use whatever filenames you want.

The first line points to the public key for the host itself. The second line points to our Mac OS machine's public key. The third points to the OS X machine's public key.

  1. Now that the remote Unix host's .ssh2/authorization file includes a pointer to the OS X machine's public key, test the connection from the OS X machine to the remote host: 
    [localhost:~/.ssh] miwa% ssh -2 rosalyn

     The authenticity of host 'rosalyn' can't be established.
     DSA key fingerprint is ee:b3:21:1b:3f:6a:57:90:59:8a:54:8d:e9:3b:24:75.
     Are you sure you want to continue connecting (yes/no)? yes
     Warning: Permanently added 'rosalyn,140.254.12.151' (DSA) to the list of known hosts.
     Enter passphrase for DSA key '/Users/miwa/.ssh/id_dsa':
     Last login: Fri Apr 20 2001 20:48:15 from ryoohki.biosci.o
     You have mail.
     You have mail.

Rosalyn miwa 1 >
  2. On the OS X machine, add the contents of the public key file that you transferred from the remote host to your .ssh/authorized_keys2 file. After doing this, our user's autho r ized_keys2 file looks like this: 
    localhost:~/.ssh] miwa% more authorized_keys2

ssh-dss AAAAB3NzaC1kc3MAAACBALzT9RbceziStHPmMiHmg78hXUgcMP14sJZ/7MH/p2NX/fB0cmbU
LPNgEN8jrs8w9N73J7yUFHSPR/LVfBj+UwkIzwjyXUW/z/VmCs25IDF/UBn1OQK5PCi16rF0F+Cx0hMN
4R3AaFAetXBdLqoom5x4Yo9gdspPqhhB44QnT43JAAAAFQDWTkKDJ2m4SApHZ/qRnRpMN5whTQAAAIAV
ADOsHpnUdUOFKjIgxZ0Hwh7IaMQ2ofGt/6PmbmNG/8zXRdxmu/JrBzieWHq6sSRSkWDSDIjuEuTkZyJ4
wx3KsLmhIrtlBw3NCcsJT2GfGQ9gEBm8fkUpeQyKAQcirbx4Hw93iMFC3g9A8cwqmA4DalKSX3un7cwe
NU32Irhq+gAAAIAz+lDSjqjFzuTV4vJ/P83nH2uwb62/iCSIB9cL32hrOm234imaAceu8pN9qqEAPr9A
ilCWa+lqGvgcdyDK0vZTvKQnk6KOU3TJfDyMR7i/gzW4P4TA/k/+YbognMCZ7SWYQXhZXWBhiPObVLYP
ffDJsLdpkyBXjZbx+Zmrmi4Bxg== miwa@ryoohki

ssh-dss AAAAB3NzaC1kc3MAAACBALPMiCqdPDGxcyB1IwPrPXk3oEqvpxR62EsspxGKGGbOM6mf60i1
hwTvjZzDhUSR7ViGeCopKtjJIqn2ljgeLbhFsQUX2UyJ6A1cFVuef0x6GVAsybqbtJc8JBh41U+iSXJK
ppEY5BI+REMydpBXJf2qT/8yZeq3NPjiOiMb6TyjAAAAFQDYvvV4WQK1Zu23q/7iLKg5j/zi5wAAAIBR
7vgrQpjKW2cprIUJsnenTm4hnBrEO7NMUomjgezrY23iZdISQlU1ESMgx9W9nnZstd2vjeqHDSmmcD2p
/aGqhl3N1WlYk8zgFYYJilPwRxVm77Np/vXz/MQpygJE7ToXGvfHqVmdBpUyakyfx6DveWhFPis1Ab8N
1RCPWm6PMwAAAIAytHjAAMYscqX2tl4icw3oOku3HIvoHBCx9D6Q9LjCqt7DqqgMN2e5vuvNz0hzqBaB
DJsjNA/A4bI88ZrgLhfJM/Nhs2xkcb7AYeHEtuGKVbsbB0EjsECtLRHydfmk3wDQjUVT92HsodFvsIl4
Je7seWUuiAEe0V1xfF7XrXuwNQ== miwa@hobbes

ssh-dss AAAAB3NzaC1kc3MAAACBAIFBAfGPtfG2xUqjT21La84K8huT12bXE1UZ8pKqBZpTFYmIbAbI
oPVvWVP0ihgWCmLKa8nGypCGx71z+9RoiDSivkCUqmIeu1vzAwFYab+F0pXc/F1Kiy1NYdvJsniPz7fP
H6btMZFkisdVFiLUfwn0mun+gdwmjbVx+V71hXZLAAAAFQCq7worKGceMLms0kPRyvcucPPqcQAAAIAu
EnKtaWkeTDqm31MC/4hr241o8E5NOqLJKcWTkOPg52a846288mihc05XUk+wa02KUvsqE+b84Q315qCM
0vDMoqofKAhvlL63XfUHO0vL94YTKJHtfvO0DhmsY7Hzk+kocSS1HtyIicA51E/EHAAvKPdi9kIliQ4d
jDVielDFbwAAAIBiUM/Wl3aPdmNgXQMTZ0b8ql6fxwbHKarBiAE3/DGpPIoDK7tWxbnS66ey0EdVQ9xh
jT/sHP9+NGykRkQg1OUv6ND8BdzJUEbhri1OosWKeVO3S/d4FitIfjNnE9CQEUj9A3AL1N1sGN5whFSI
v12T9e49ubniYjWoLVwG8KH+Jw== miwa@Rosalyn

The first line is the public key for the OS X machine itself. The second is a blank line. The third is the public key for the Mac OS machine. The fourth line is a blank line. The fifth line is the public key for the remote Unix host.

  1. Now that the .ssh/authorized_keys2 file includes a copy of the public key for the remote Unix host, test a connection from the remote host to the OS X machine: 
    Rosalyn miwa 1 >ssh2 ryoohki

     Passphrase for key "/home/miwa/.ssh2/id_dsa_1024_a" with comment "1024-bit dsa,

            ccc.gif
          miwa@Rosalyn, Mon Apr 16 2001 17:23:31":
     Welcome to Darwin!

[localhost:~] miwa%

Pubic Key Authentication in SSH1

In this section, we will demonstrate how to enable public key authentication for SSH1 servers. Unlike public key authentication with the two most popular types of SSH2 servers, the two most popular types of SSH1 servers implement public key authentication in the same way. We will demonstrate enabling public key authentication between a Mac OS machine and a Unix machine. Then we will enable public key authentication between an OS X machine and another Unix machine.

Authentication Between a Mac OS Machine and Unix Machine

As with SSH2, it is easiest to start the process of enabling public-key authentication on the Unix machine. Starting with the Unix machine provides an opportunity to more quickly see what the F-Secure client will do on your Mac OS machine. Additionally, it starts to prepare the user to be able to connect from the Unix machine to other machines via public key authentication.

  1. On the Unix machine, generate public and private keys by running ssh-keygen or ssh-keygen1. Which one you will use depends on the host. On some systems, ssh-keygen defaults to the SSH2 protocol. To do anything SSH1-specific on those systems, append 1 to the end of the command. In OpenSSH, ssh-keygen defaults to SSH1 unless the option for generating an SSH2 protocol key is used.

This Unix host is running SSH2 and SSH1 servers, so ssh-keygen1 has to be used:

Rosalyn miwa 1 >ssh-keygen1

     Initializing random number generator...
     Generating p:  ................++ (distance 224)
     Generating q:  .....++ (distance 92)
     Computing the keys...
     Testing the keys...
     Key generation complete.
     Enter file in which to save the key
      (/home/miwa/.ssh/identity):
     Enter passphrase:
     Enter the same passphrase again:
     Your identification has been saved in
     /home/miwa/.ssh/identity.
     Your public key is:
     1024 35  1233312813655580342629444440019705730527794755700146

      ccc.gif
    2510447921204589975264176684977834967422442955486232

      ccc.gif
    2759148790022277518022104954840563331735710347611258

      ccc.gif
    4401245696271560346079612184349553815058693112556130

      ccc.gif
    9028548711559684218705529622437924369765037766990458

      ccc.gif
    8920718940456117968631232063576786600240415013401
miwa@Rosalyn
     Your public key has been saved in
     /home/miwa/.ssh/identity.pub

On this remote host, the private and public keys are saved to the directory called .ssh. This is where the files for both SSH1 and SSH2 keys are stored in OS X.

As you also saw with SSH2, the user is prompted for a passphrase to protect the private key. The same recommendations for creating a passphrase still apply. It should be at least 11 characters long and include as many character types as possible: uppercase letters, lowercase letters, numbers, and special characters. Spaces may be also included as part of the passphrase.

  1. In the .ssh directory, copy identity.pub to authorized_keys.pub. The file authorized_keys is where the host stores the SSH1 public keys of authorized hosts. As with SSH2, anyone who has the matching private key for a given public key in this file is authorized to connect to this host as this user.
  2. Test that your passphrase works if you connect from this remote host to this remote host. As shown here, this works for our user: 
    Rosalyn miwa 9 >ssh1 rosalyn

     Enter passphrase for RSA key 'miwa@Rosalyn':
     Last login: Fri Apr 13 16:05:09 2001 from rosalyn.biosci.o
     You have mail.

Rosalyn miwa 1 >
  3. In the .ssh directory, save another copy of identity.pub to some other name that lets you know that it is the public key for this remote host, such as <hostname> -ssh1.pub.
  4. On the Mac OS machine, connect to the remote host via the usual password authentication method in F-Secure SSH 1.0.2.
  5. Under the Edit menu, select Connection Properties. Click on the RSA Identity tab, which brings up the panel shown in Figure 26.34, if it is not already the tab showing.
    26fig34.jpg

    Figure 26.34 Generating a key pair in F-Secure SSH 1.0.2 starts with the RSA Identity section of the Properties dialog.

  6. Click on New. An RSA identity generation dialog box like that shown in Figure 26.35 appears. Do the following:
    • Enter a comment in the suggested form of <user> @ <macintosh> .
    • Enter a passphrase using the same guidelines you saw earlier.
    • Enter the passphrase again for verification.
    • The default and recommended key length is 1024 bits. It is not necessary to adjust the default.
    • Click on Generate key.
      26fig35.jpg

      Figure 26.35 Specify the parameters of your keys in the RSA identity generation dialog.

  7. Just as when you first started F-Secure SSH 1.0.2, move your cursor around in the window to initialize the random number generator.
  8. Save the key pair as instructed. The name of the file defaults to IDENTITY. If multiple users use the Mac OS machine, it is recommended that for easy sorting, each user store her keys in her own folder in the F-Secure SSH folder.
  9. Click OK in the dialog box that tells you that your identity has been filed as you specified it should be.
  10. The RSA Identity section of the Properties box reappears, with some additional information filled in as shown in Figure 26.36. Verify that the identity file has been properly selected.
    26fig36.gif

    Figure 26.36 The selection of the identity file now appears in the RSA Identity section of the Properties dialog.

  11. If Copy is available as a selection, click on it. If it is not, click on OK. Then bring up the RSA Identity window again and click on Copy, assuming that your identity file is still selected. Copy copies your public key to the clipboard. An information dialog like that shown in Figure 26.37 should appear.
    26fig37.jpg

    Figure 26.37 The informative dialog box that appears when you copy tells you where on the Unix side to paste your public key.

  12. On the Unix machine, create a file with a name that lets you know it is the SSH1 public key for your Mac OS machine. You could call it something like <macos-host> -ssh1.pub.
  13. Make a backup copy of .ssh/authorized_keys. Edit .ssh/authorized_key in your favorite text editor. Add to it a blank line and a line that contains the contents of <macos-host> -ssh1.pub. Here is what the .ssh/authorized_keys file of our user miwa looks like at this stage: 
    1024 35 123331281365558034262944444001970573052779475570014625104479212045899752
64176684977834967422442955486232275914879002227751802210495484056333173571034761
12584401245696271560346079612184349553815058693112556130902854871155968421870552
96224379243697650377669904588920718940456117968631232063576786600240415013401 mi
wa@Rosalyn

1024 35 909400270068835789365340764432579481890601265942027673338014578714246240
08941333767613393457884572605367686913264231165534818281623120501426552405476133
86011470780123940481672833879017816652256472285975437039764248048300592030161507
1190666939214904116358241550344838704220243882868572485328230167776925913357 miw
a@hobbes
    Notice that the form of a public key for SSH1 is one line containing: 
    1024 two-digit-number lots-of-characters 
         <user>@<host>
    The 1024 is the key length, though we've never seen it generate anything other than 1024 bit keys. This looks familiar, doesn't it? It looks like the OpenSSH SSH2 public key follows a form similar to SSH1 public keys! If what you copy to the Unix side looks nothing like the form shown here, go back to the copy step and try again. Sometimes the copy step goes very smoothly. Other times, it is very frustrating, and random data can be pasted over instead of your key. We've observed no pattern to the problematic instances, so if you have problems, read the instructions and try it over again—chances are it will work properly the second time around.
  14. Log out of the remote host.
  15. Start another connection to the Unix host in F-Secure SSH 1.0.2. So that you have the option to connect via public key authentication, do not use your desktop alias to make this connection.
  16. This time, rather than entering your password, select the RSA. Then click OK. Save your settings to an alias to your desktop, if you expect to log in regularly with your passphrase.
  17. A dialog asking you to enter your passphrase appears. At this point, you're back on familiar territory. Enter your passphrase and click OK.

You should now be logged in to the remote host. If you end up having to connect via password instead, check some of the basics. Make sure that F-Secure SSH 1.0.2 selected your identity file. Make sure your .ssh/authorized_keys really does have the additional key included. If the additional key is included, make sure that it is on one long line, rather than separate lines with returns. If all else fails, start over from scratch.

If you were successful, you might want to update the passphrase alias you saved to the desktop by including your tunnels, too. You can also modify your tunnel connections so that you connect via public key authentication. Unfortunately, you still have to use a password in the FTP or e-mail client.

Public Key Authentication Between Unix Machines

Because the SSH1 format does not vary among the popular SSH1 servers, public key authentication between Unix machines is also easier than what you saw in SSH2. In this example, we will look at public key authentication between an OS X machine, which runs OpenSSH, and a Unix machine running the other popular SSH1 server.

At this point, you should be able to figure out what to do. If one of the Unix hosts involved is also the one that your Mac OS machine connected to, you have even already done some of the work. Because we know that the procedure for enabling public key authentication is easy to forget if you don't have to do it often, we include the procedure from start to finish.

  1. On Unix host A:
    • Generate public and private keys by running the SSH1 version of ssh-keygen.
    • Create the file that holds the set of authorized public keys: 
      cp .ssh/identity.pub .ssh/authorized_keys
    • Test that your passphrase works by connecting from Unix host A to Unix host A.
    Make a backup copy of your public key. Name it something that is easily identifiable to you when you are on a remote host. If given a good name, the backup copy is probably the most informative copy to transfer to other hosts. 
    cp .ssh/identity.pub .ssh/<host-A>-ssh1.pub
    • Transfer a copy of your public key on host A to host B.
  2. On Unix host B:
    • Generate public and private keys by running the SSH1 version of ssh-keygen.
    • Create the file that holds the set of authorized public keys: 
      cp .ssh/identity.pub .ssh/authorized_keys
    • Test that your passphrase works by connecting from Unix host A to Unix host A.
    • Make a backup copy of your public key. Name it something that is easily identifiable to you when you are on a remote host. If given a good name, the backup copy is probably the most informative copy to transfer to other hosts. 
      cp .ssh/identity.pub .ssh/<host-B>-ssh1.pub
    • Transfer a copy of your public key on host B to host A.

Edit .ssh/authorized_keys to include the public key from host A. Remember that the public key for a host is on one line only. Each public key contained in .ssh/authorized_keys should be only one line long without any returns or spaces. This is the same behavior we saw with .ssh/authorized_keys2 on an OS X machine. Here is a sample .ssh/authorized_keys file on host B for our user, miwa:

[localhost:~/.ssh] miwa% more authorized_keys

1024 35 143360183656224498601121073193820768197357701013476215869370944931688223
70498617132214779624465699914141070434905449681454367814018069875143895388524470
19352815589514827160032787798907350704733661779740452707216917600539436223551843
18929710444902977738093095078515316484912505255167577812945106499724460880449 mi
wa@ryoohki

1024 35 909400270068835789365340764432579481890601265942027673338014578714246240
08941333767613393457884572605367686913264231165534818281623120501426552405476133
86011470780123940481672833879017816652256472285975437039764248048300592030161507
1190666939214904116358241550344838704220243882868572485328230167776925913357 miw
a@hobbes

1024 35 123331281365558034262944444001970573052779475570014625104479212045899752
64176684977834967422442955486232275914879002227751802210495484056333173571034761
12584401245696271560346079612184349553815058693112556130902854871155968421870552
96224379243697650377669904588920718940456117968631232063576786600240415013401 mi
wa@Rosalyn

In this example, line 1 contains the public key for the host itself, host B, which is our OS X machine. Line 2 is a blank line. Line 3 is the public key for the Mac OS machine. Line 4 is a blank line. Line 5 is the public key for host A, another Unix machine.

  1. Now that the .ssh/authorized_keys file on host B includes host A's public key, test a connection from host A to host B. For our user miwa, the test is successful: 
    Rosalyn .ssh 4 >ssh1 ryoohki

     Host key not found from the list of known hosts.
     Are you sure you want to continue connecting (yes/no)? yes
     Host 'ryoohki' added to the list of known hosts.
     Enter passphrase for RSA key 'miwa@Rosalyn':
     Warning: Remote host denied X11 forwarding, perhaps xauth program could not be run on

            ccc.gif
          the server side.
     Welcome to Darwin!

[localhost:~] miwa%
  2. Edit .ssh/authorized_keys on host A to include the public key from host B.
  3. Now that the .ssh/authorized_keys file on host A includes host B's public key, test a connection from host B to host A. For our user miwa, this test is also successful: 
    [localhost:~] miwa% ssh rosalyn

     Enter passphrase for RSA key 'miwa@ryoohki':
     Last login: Sat Apr 21 01:46:08 2001
     You have mail.
     You have mail.

Rosalyn miwa 1 >

Share ThisShare This

Informit Network