SSH: It keeps asking the passphrase!

[Filipe_1]

Greetings Forumers,

We have here two servers. A Sun Solaris with Openssh 3.1 and a HP-UX with OpenSSH 3.8, OpenSSL 0.9.7d.
We are trying to stabilish a trusted relationship by SSH between both servers, and despite the DSA key is being generated without a passphrase ( ssh-keygen -t dsa -N"" ), when we try to login, the passphrase is still being asked.
We are clueless at this time and any help would be much appreciated.

If anyone knows a more adequate forum for this issue, please let us know.

Tha printout of the problem is attached.

Thanks, Filipe.

[RAC_1 · Accepted solution]

You will better off setting the keys in $HOME/.ssh/authorized_keys file. Put the keys in that file on both hosts. Attaching a HP secure shell document to set it up.

Hope this helps.

Using H/P's Secure Shell & Secure Copy


Purpose:

As we migrate to more secure systems, convenient utilities such as FTP and TELNET will be replaced with more secure systems. Secure Shell (ssh) and Secure Copy (scp) are the standard replacements for these. Over time, the insecure utilities will be completely blocked from use, so all users with HP Unix accounts will need to become familiar with these. Because of the authentication and encryption, making a connection initially is slower than the insecure systems. But once the connection is made, they are equally as fast and convenient.

Authentication & Encryption

Both ssh and scp use public/private key encryption. This document will not cover the theory behind this authentication and encryption algorhythym. This is covered in Practical Unix & Internet Security: 2nd Edition (Garfinkel/Spafford, © 1996, 1991 O'Reilly & Associates, Inc.) in considerable depth. This document will concentrate on the actual use of this technology rather than the theory.


Setting up the keys

1. It is most efficient to take the time to set up all hosts at the same time. If you have an account on 6 machines, set up all 6 at the same time. If you later are granted access to another machine, it is your responsibility to make the modifications to all of them. This is the responsibility of each user rather than a job for the systems administrator.
2. Fastest/easiest way to set up the key files.
a. Open a session on one host using CDE (Citrix Metaframe for Unix is best). Open a standard text terminal session inside the CDE desktop.
b. Also open the text editor from the CDE desktop.
c. On the terminal session, type ssh-keygen -t dsa. Press for the next 3 questions. Do NOT use a passphrase unless instructed to do so by Security, or if standard policies change.
i. The above command will create the .ssh directory under the users' home directory.
ii. It will also create 3 files, you will add a fourth, and a fifth will soon appear.
d. Change into the .ssh directory with cd ~/.ssh.
e. Next, display the public key created with the previous step: cat id_dsa.pub. This will show the lengthy public key.
f. Highlight that public key by holding the left mouse button down, and dragging the cursor down across the displayed characters. There are a LOT of them. The very last will be your user name and the host on which you're working. Make sure that they are all highlighted, but nothing else.
g. At the top of the menu bar, click Edit --->Copy. This loads the character string into the CDE paste buffer
h. Next, move the cursor into the menu bar of the text editor. Click Edit-->Paste. This writes the paste buffer into the text file. At the end of the line, type a single so that the carriage returns to the far left.
i. Return to the text terminal session by clicking on its menu bar. Ensure that your home directory has appropriate permissions. Type cd ../.. which will move up two directories in the hierarchy. List the directory with ll. On the far left, the permissions should read drwxr-xr-x. If they don't, change them with chmod 755 . The secure utilities will not work properly if these permissions are not correct.

j. Next, open a session on the next host on which you will use the secure utilities. Type ssh . You will be challenged with: The authenticity of host ' (ip address)' can't be established. RSA key fingerprint is (long hexadecimal number). Are you sure you want to continue connecting (yes/no)? Answer yes.
k. You will next see Warning: Permanently added '(hostname) (IP address) ' (RSA) to the list of known hosts. You will then be challenged for your password, as normal.
l. Close the session on remote host, return to the standard terminal session on the host. Next, either open a session on another remote host, or continue with step m below if you have completed steps c-k, above on all hosts. You will be creating a text file with the contents of the id_dsa.pub file from each host, separated by a carriage return.
m. When steps c-k have been done on all hosts, save the text file. Click on File-->Save As, and enter /(the path to your home directory/.ssh/authorized_keys. It is essential to save this file in this particular directory with this particular filename. Be sure that this path/filename is in the box near the bottom of the popup window.
n. Next, ensure that the authorized_keys file has the proper permissions. Return to the home session on the first system. Then change into the .ssh directory with cd ~/.ssh.
o. List the .ssh directory with ll. The authorized_keys files should show -rw-r--r-- on the far left. If not, change the permissions with chmod 644 authorized_keys.
p. Next copy the authorized_keys file into the .ssh directory of each remote host on which you ran steps c-k, with scp authorized_keys HOST:/(my home directory)/.ssh/authorized_keys.
q. Lastly, open a session on each host that has the authorized_keys file, with ssh . You will be challenged for a password, but if the previous steps have been done exactly, this will be the last time. You can check this by logging off (with exit or ), then logging on again. You should not be challenged for a password. If so, check permissions as above before opening a help desk ticket.
r. You might want to open a session ON each host, TO each host. Again, you should only be challenged for a password the first time. Afterwards, you may ssh or scp securely without being prompted for a password.
s. If you are later granted access to another host, you must add the contents of its ~/.ssh/id_dsa.pub file to each ~/.ssh/authorized_keys file

[Steve Steel]

Hi

http://www.csua.berkeley.edu/ssh-howto.html


Should help


Steve Steel

[Steven E. Protter]

Attaching a Chris Vail word doc. Same basic premise.

Your version numbers are a little divergent and problems could be related to taht. I'd recommend getting a more current version on your Solaris platform.

SEP

[Sridhar Bhaskarla]

Hi Filipe,

When you ran the command 'ssh-keygen -t dsa -N""', did it complete successfully?. There should be a space between '-N' and "". What are the timestamps on .ssh/id_dsa* files?.

-Sri

[Sanjay_6]

Hi Filipe,

Maybe this link will help,

It tells you how to config the ssh to login from one box to another without password,

http://bumblebee.lcs.mit.edu/ssh2/

Hope this helps.

Regds

[Andrew Cowan]

Have you checked the file access permissions on the files in the "~/.ssh"? If "STRICTMODE" is set to "YES" SSH will reject your keys unless the permissions are correctly set.

The other major cause of failure is when the two machines know each other by different names. Simply login to the remote machine and do a "who am i" and ensure that the response is the same as the name in the "authorized_keys" file.

[Christian Hettler]

how about file permissions on authorized_keys?
Permissions should be 644.

ch

[Gordon Morrison]

Hi filipe,
This works for HP-UX:

To use ssh between hosts without a password:

First, on host1 you need to make sure that a directory called .ssh exists in the user's home directory (we'll assume root). To keep it secure, create it with 700 permissions:

mkdir -m 700 .ssh

Then you need to generate a public/private key pair:

ssh-keygen -t dsa -f ~/.ssh/id_dsa

Now copy the public key to host2:

cd .ssh
scp id_dsa.pub root@host2:~/.ssh/id_dsa.tmp
(You still need to supply the password at this point)

Now on host2, add that public key to the list of authorised keys:

ssh host2
(Password still needed)
cd .ssh
cat id_dsa.tmp >> authorized_keys
(Note American spelling!!! "authorized" with a zed)
chmod 640 authorized_keys

root on host1 can now login to host2 without a password.

To get this working in both directions (i.e. root on host2 can also log in to host1 without a password), you basically do the same thing in reverse: Create a public key on host2 and copy it to host1.
NOTE: Do not overwrite the original id_dsa.pub file, or you will have un-done all of the above. Also, do not overwrite the authorized_keys file: just append to it.

Basically the key in id_dsa.pub on the local host must match an entry in the authorized_keys file on the remote host for the password to be skipped. The authorized_keys file can contain several entries. Just keep appending to it as shown above.

Hope that helps
Gordon