HP-UX Secure Shell - Setting up SSH to Use Public Key Authentication.

HP-UX Secure Shell - Setting up SSH to Use Public Key Authentication.

Overview

Using public key authentication while setting up Secure Shell (SSH) on HP-UX systems

Procedures

Public key authentication is a good choice for user authentication since it provides some of the best security available. The steps outlined below assume that both the client and server are running the HP-supplied version of Secure Shell. This version will interoperate with other platforms and implementations but specific configuration options may differ. On the client node: Generate a key pair using the SSH-keygen program while logged in with the regular user's ID. Generate at least one key pair. If SSH-2 protocol is being used (the default on HP-UX), key types of either DSA or RSA may be chosen. If SSH-1 protocol is going to be used, a key type of RSA1 will need to be used. Generate the keys as:      # ssh-keygen -t dsa        Generating public/private dsa key pair.       Enter file in which to save the key (/home/flyingfox/.ssh/id_dsa):       Enter passphrase (empty for no passphrase):       Enter same passphrase again:       Your identification has been saved in /home/root/.ssh/id_dsa.       Your public key has been saved in /home/root/.ssh/id_dsa.pub.       The key fingerprint is:       a9:11:f6:af:31:45:31:fc:52:25:a1:52:da:bc:0e:3e flyingfox@lei Take the default file name for the location of the key(s) by hitting the Enter key . It is also suggested to use a passphrase to protect the private key. The passphrase may be any string of characters or a phrase, including white space. The SSH-keygen program may be run once for each key type that needs to be generated. Unless there is a reason to use non-default values, just generate the single DSA key pair as shown above. The public key that was just generated must be copied over to the SSH server. The public key will have been placed in a file as noted by the SSH-keygen program but with a .pub at the end of the name. Example: /home/flyingfox/.ssh/id_dsa.pub . Any mechanism may be used to get the key over to the SSH server. For example:    $scp /home/flyingfox/.ssh/id_dsa.pub server:/home/flyingfox/client.key       wilfor@gozo's password:       id_dsa.pub           100% |*****************************|   601       00:00     $ On the server node: Append the client's public key copied over in step 2 above to the end of the file: # cat /home/flyingfox/client.key >> /home/flyingfox/.ssh/authorized_keys If the file or the .ssh subdirectory does not exist, they must be created manually. The SSH daemon (sshd) on the server will check the owner and permissions on the authorized_keys file to be sure it is writable only by the user (and root). If it is not safe , then sshd will ignore the file. A mode of 600 should work well. The SSH server will also check the modes and owners of all the directories in the path to the authorized_keys file to be sure that they are safe as well. Typically, /home should be writable only by root, and the users home directory and the .ssh subdirectory should be writable only by the user (and root). If both the client and server are set up correctly, then there should be a prompt for the passphrase when connecting from the client to the server via SSH (or scp/sftp). If the private key was not protected with a passphrase, then there will not be any prompt and will automatically log in to the server. If providing a passphrase each time the SSH is run is not desired, it is recommended to use the ssh-agent(1) program to cache the keys for an entire session rather than leave the private key un-protected (null passphrase). Leaving the private key un-protected is a security risk if anyone can obtain a copy of the private key file.

Keywords.

RSA,SCP.