"Usually at a time like this, I'll bluff." -- G. Carlin
If the server refused your key, well, maybe you're using the wrong key?
After you generated the new key did you copy the public portion into the
server-side authorized_keys file? And get rid of the old one? I know
this seems basic but whenever I've been futzing around with something
like this for a while I find that I often start forgetting the basic
steps because "surely I've done this part already..."
Something else that can happen is that the server gets confused about
whether you really are connecting from "hostB" or "hostB.domain.com" or
"CNAME-for-hostB.domain.com" or some such. They aren't equivalent as
far as sshd is concerned. Maybe check the server-side logs for clues on
this, and then adjust the proper line in authorized_keys so that the
host name matches whatever your server thinks your client's name is.
I've also been known to cheat:
1024 35 1234reallylongrandomnumber5678 [EMAIL PROTECTED]
1024 35 1234reallylongrandomnumber5678 mjinks@foo
1024 35 1234reallylongrandomnumber5678 [EMAIL PROTECTED]
That way no matter what the server gets for a reverse lookup (FQDN,
non-FQ-DN, or IP), you're covered.
Another bit of mojo that sometimes helps is to make sure that you've
logged in from the "server-side" machine back to the client since the
installation of your key; this can sometimes sort out difficulties in
associating the right key with the right host, although just now I
forget the exact mechanics of that.
Good luck,
-m
"Curtis, Darren S" wrote:
>
> Michael,
>
> The -v helped tons. The problem was that the permissions
> on the ~/.ssh/authorization was 664 instead of 600. I
> changed the perms and it worked but I had to supply the
> passphase. I generated a new key pair (ssh-keygen) and
> left the passphrase empty. Now the server refuses the
> connection and asks me for the user's login password.
>
> The output is:
> debug: Encryption type: 3des
> debug: Sent encrypted session key.
> debug: Installing crc compensation attack detector.
> debug: Received encrypted confirmation.
> debug: Trying RSA authentication with key 'user@hostB'
> debug: Server refused our key.
> debug: Doing password authentication.
>
> Any ideas on how I can type:
> ssh hostB date
> and get the output without typing a passphrase or password?
>
> Thanks again,
>
> Darren Curtis
>
> -----Original Message-----
> RSA authentication can be a bit tricky to set up if you aren't used to
> it. Have you tried running ssh manually as the user in question? The
> -v switch can be really useful when RSA isn't working as expected, as
> the output should tell you right where SSH is falling down.
>
> "Curtis, Darren S" wrote:
> >
> > Hello,
> >
> > I have looked through all the documentation and the FAQs
> > and can still not find out a way (that works) to use ssh
> > as a direct replacement for rsh.
>
> --
> Michael Jinks, IB // Technical Entity // Saecos Corporation
--
Michael Jinks, IB // Technical Entity // Saecos Corporation
