UNIX for Advanced & Expert Users

Thanks grial. It is odd indeed. I had tried rsa before dsa and here is the outcome of the re-try:

debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying public key: /home/testuser/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying public key: /home/testuser/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
testuser@rmt_srvr's password:

Still asking for the password!!

very strange. Try cleaning up the keys file on the remote end.
1. move the .ssh/authorized_keys file out of the way (rename it to something).
2. scp the public backover
3. on the remote end rename the public key you just scp'd over to be .ssh/authorized_keys
4. logout and try again

On my system (OpenSSH_4.7p1, OpenSSL 0.9.8g 19 Oct 2007 on Archlinux testing to OpenSSH.4.3.p2_Debian-9 on Debian Etch) I get the following:

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/chris/.ssh/identity
debug1: Trying private key: /home/chris/.ssh/id_rsa
debug1: Offering public key: /home/chris/.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 435
debug1: read PEM private key done: type DSA
debug1: Authentication succeeded (publickey).

I assume the different messages are just because of different versions, possibly.

PS don't forget to check the ownership and permissions on the files in ~/.ssh/

I like to keep mine very restrictive at 0700 for the directory and 0600 for the files, the maximum that OpenSSH seems to allow is 0644 for the files.

Thanks wempy.

I had done all these "tricks" before posting my request here.
I believe it is somewhere deep in either OpenSSH and/or Solaris 8!!

Let's step back a second and revisit the key pair that you'd generated. From your post:

Passphrase has apparently gained the misnomer of equal to the password, unfortunately. It's not, and it's intended to serve as a means to ensure public sharing of the key-pair without granting full account access to the remote host. Also, you don't need (or want) to specify your passphrase (ie, -P "") on the command-line, as it can be used against you, should anyone gain access to your key-pair and/or .sh_history file.

Instead of using -P (which is really intended to allow for revision of the passphrase in a given key-pair), let the ssh-keygen program prompt you for your passphrase. Leave all other switches as they are, but scratch the

Code:

-P ""

options. The program will prompt you for the empty passphrase..to which you'll just enter twice. It doesn't matter what key type you're creating either..same goes for rsa and dsa.

Lastly, just be sure that you're placing the Public Key into the remote user's .ssh directory as well. You don't have to have identical users between the machines..or even have separate machines for that matter (ie, unilover@localhost can access unilever@localhost, much the same as unilover@localhost can access unilever@remotehost or unilover@remotehost). So long as the key placement is done right..you can automate the login with an empty passphrase.

HTH

Thanks curleb.

I regenerated the Public-Key on the localhost per your instructions and copied the contents to the .ssh/authorized_keys on the remotehost.

Mind you, NOTHING CHANGED!!

Had I to copy over the "id_dsa & id_dsa.pub" pair of files too?!?!

No, only the .pub file goes to the remote location..you cat it into the ~/.ssh/authorized_keys file and scratch the original .pub file.

One thing I'd caution you on..and many of the SAs I deal with can't quite grasp: are you sudo or sesu or similar while trying to do any of this? This throws off the EID of the process and SSH won't let on, for obvious reasons.