Technology. People. Projects….Results.

Trusted Authentication with openSSH

 Tip courtesy of Kyle Reynolds at http://www.camelrichard.org

Trusted authentication with OpenSSH

1. Change directory to the .ssh (hidden directory) located under your home
directory, or create it (mkdir -m 755 ~/.ssh).

2. Create the necessary 1024 bit public and private keys for type dsa, version 2,
of ssh (-t dsa).

                    ssh-keygen -t dsa -b 1024

3. When prompted for values you may take the default file names.  This will
generate two files in the .ssh directory that are married to one another.  It
will overwrite existing key files with the same name if they exist.  The two
files generated are:

          id_dsa (private key file)

          id_dsa.pub (public key file)

4. Just hit [return] twice, entering an empty passphrase. This allows no password
to be required for authentication checks between the two-paired key files. In
short the password in null.

5. Copy the public key file (id_dsa.pub) to the remote host you would like to
authenticate against.

6. Rename, copy, or append the public key file or contents to “authorized_keys2″
and place it in the .ssh directory of your home on that remote host.

NOTE:  All public keys are stored in this file; therefore, you should APPEND the
contents of the id_dsa.pub file to an existing authorized_keys2 file allowing for
multiple host authentication.

You.re DONE!

CREATION EXAMPLE:

username1@servername1 $ ssh-keygen -t dsa -b 1024

Generating public/private dsa key pair.

Enter file in which to save the key (/u01/home/username1/.ssh/id_dsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /u01/home/username1/.ssh/id_dsa.

Your public key has been saved in /u01/home/username1/.ssh/id_dsa.pub.

The key fingerprint is:

aa:82:47:56:35:b3:9f:4e:d0:89:c1:a8:dc:b6:43:cb username1@servername1

username1@servername1 $

Example listed of the .ssh directoy.

drwx——   2 username1  sysadmin     512 Nov 29 13:58 ./

drwxr-xr-x  34 username1  sysadmin    2048 Dec  6 09:47 ../

-rw-r–r–   1 username1  sysadmin    1816 Jul  5 10:59 authorized_keys2

-rw——-   1 username1  sysadmin     668 Jun  4  2002 id_dsa

-rw-r–r–   1 username1  sysadmin     604 Jun  4  2002 id_dsa.pub

-rw-r–r–   1 username1  sysadmin   60777 Nov 18 13:11 known_hosts2

-rw——-   1 username1  sysadmin    1024 Dec  7 00:05 prng_seed

authorized_keys2 = One or more public keys copy from remote hosts.

id_dsa = ssh version 2 private key for current host.

id_dsa.pub = public key to copy to remote host

known_hosts2 = stores all fingerprints which are written when you answer “yes”
at first login attempt to a remote host via ssh.

TROUBLESHOOTING:

If ssh is still prompting for a password to authenticate, check permissions on
the home directory and .ssh directory.  The ssh binary is smart enough to deny
(prompt you for a password) if one or both directories are world writeable. 
Recommended umask is 022 or permissions of 755.

You may delete the known_hosts2 file, for an existing host entry without hurting
anything.  You will just be prompted to answer “yes” or “no” again because ssh
treats it as a first login attempt again.

The files .authorized_key2. and .known_hosts2. may also be named without the
number 2 at the end (.authorized_keys. .known_hosts.).

Another common problem is that the user.s shell account is not a valid shell
listed in the /etc/shells file. This occurs most often when the account is an
application account, the shell is .false. or .true. and the account is locked
(*LK*).  Just add ./path/false. or ./path/true. to /etc/shells.