Solution:
When using the file transfer protocol, FTP, one can easily create a script that can be scheduled to automatically transfer files from one system to another in an unattended mode. Typically, the login credentials (user ID and password) are coded within the script as part of the command that makes the connection between the two devices. However, the use of this method is insecure in that it transmits data in a readable form, including the password used to connect the workstation to the server. Thus, any individual who has access to network equipment, or who possesses an inexpensive device that can observe wireless traffic, may view such and potentially use such data.

To address this issue, a protocol known as SFTP or Secure File Transfer Protocol was developed. To prevent the exposure of password to anyone having access to file transfer scripts, the designers of SFTP did not provide the ability to include passwords in script commands. Instead, they provided an alternative method of authenticating users attempting to use the protocol in an unattended manner.

This method employs two large sequences of characters, known as public and private keys, that serve as encryption and decryption keys between the two devices. These keys are uniquely crafted so that whatever data is encrypted by one key of the pair can only be decrypted by the other.

To use public and private keys with scripted SFTP interactions, you must first generate a public/private key pair on your system using a utility program either provided by their operating system or by a third party software vendor. You then need to copy your "public" key into a predetermined directory location on any server that you wish to transfer files to/from. When the SFTP session begins, the workstation and the server will authenticate each other by ensuring that a test value that the workstation encrypts with the private encryption key can be decrypted by the server using the public encryption key.

Instructions for Creating and Installing Public/Private Keys On a Windows Workstation using the SSH Secure Shell application

1. Generate the Key Pair

• Start the SSH Secure Shell application on your Windows workstation
• Open an ssh session with a host computer that you plan to transfer files to or from
• From the Edit menu select Global Settings
• Click on Keys under "User Authentication"
• Click the "Generate New" button
• Leave default options (unless you know what you want to change) and click next.
• Click next after key has been generated.
• Enter a file name (Suggested name "id_dsa"). Comment is optional. If you leave passphrase boxes blank, no password will be needed when transferring files, but you will be prompted by a warning box that you have an empty passphrase. Click yes.

CAUTION - If you enter a null pass phrase, no password will be needed when transferring files or opening terminal sessions between your workstation and any target system that you will configure in step 2. Thus, it is critical that you keep your workstation secure, since anyone who has access to your system will be able to open terminal sessions with and transfer files to/from the target server in your name without a password.

2. Upload the Public Key to the Target Servers

• Click upload keys button. This will show you the name of the key and the destination folder of .ssh2 along the the authorization file name. Change the destination folder to .ssh. The authorization file value can be ignored.
• Go back to the ssh session window.
• On the server, change your working directory to ~/.ssh
• If you used the file name suggested for your keys, run the following command to authorize the public key: ssh-keygen -i -f id_dsa.pub >>authorized_keys

If you used a different file name than "id_dsa" for your keys, replace "id_dsa.pub" in the above command with the name you gave the file at creation time followed by the ".pub" extension.

NOTE - The file authorized_keys should have its file mode value set to 600 (read/write by owner only). If it does not, enter the following command: chmod 600 authorized_keys

3. Test the configuration

• Log out of the target server.
• Open an ssh session with the server again. You should not be prompted for a password.

-------------------------------------------------------------------------

Instructions for Creating and Installing Public/Private Keys On a Macintosh OS X or Linux Workstation

1. Generate the keypair.

• Open a terminal window.
• At the command line, create the SSH public/private key pair by entering: ssh-keygen -t dsa
• When prompted for a location to save the key, press the return key to use the default value, for example:
  /Users/[your OS X ID]/.ssh/id_dsa (for Mac OS X)
  /home/[your Linux ID]/.ssh/id_dsa (for Linux)
• When prompted for a pass phrase, you may press the return key for a null pass phrase, if that is desired.

CAUTION - If you enter a null pass phrase, no password will be needed when transferring files or opening terminal sessions between your workstation and any target system that you will configure in step 2. Thus, it is critical that you set your file permissions to prevent anyone from accessing to your /Users/[your OSX ID]/.ssh/id_dsa file, or your /home/[your Linux ID]/.ssh/id_dsa file, since anyone who can copy that file will be able to open terminal sessions with and transfer files to/from any authorized target server in your name without a password.

2. Upload the Public Key to the Target Servers

• Copy the public key from the Mac to any host where it is to be used (e.g. yuma) by entering the following into Mac OS X Terminal command line: scp id_dsa.pub [netid]@yuma.princeton.edu:~/.ssh/
• Enter your LDAP password (not the key passphrase, if any) at the prompt.
• Log in with ssh to the target server as usual, entering the LDAP password again
• Once logged in, change your working directory to ~/.ssh. Note - If the directory .ssh does not exist, you may have to create it using "mkdir .ssh" first.
• Then, run the following commands to authorize the public key:
  cat id_dsa.pub >> authorized_keys
  rm id_dsa.pub

NOTE - The file authorized_keys should have its file mode value set to 600 (read/write by owner only). If it does not, enter the following command: chmod 600 authorized_keys

3. Test the configuration

• Log out of the target server.
• Open an ssh session with the server again. You should not be prompted for a password.