* Britton (fsblk@aurora.uaf.edu) [010802 14:08]: > > I can use passworless ssh login just fine by copying the public key to the > ~/.ssh/authorized_keys2 of the machine I want to ssh to, without any > modification to /etc/ssh/ssh_config, provided the public key was generated > with ssh-keygen -t dsa and the passphrase left empty. When I try exactly > the same procedure, but the key type rsa (begin the procedure with > ssh-keygen -t rsa instead of sh-keygen -t dsa), I am always promted for my > password. > > Is this a bug, or is there some distinction between the two key systems > that causes this behavior? Here is the most verbose output of the two > approaches disscussed above: > <lots of output snipped; this is the tail of the rsa-not-working output> > debug1: got SSH2_MSG_SERVICE_ACCEPT > debug1: authentications that can continue: publickey,password > debug3: start over, passed a different list publickey,password > debug3: preferred publickey,password,keyboard-interactive > debug3: authmethod_lookup publickey > debug3: remaining preferred: password,keyboard-interactive > debug3: authmethod_is_enabled publickey > debug1: next auth method to try is publickey > debug2: userauth_pubkey_agent: no keys at all > debug2: userauth_pubkey_agent: no more keys > debug2: userauth_pubkey_agent: no message sent > debug1: try pubkey: /home/bkerin/.ssh/id_rsa > debug3: send_pubkey_test > debug2: we sent a publickey packet, wait for reply > debug1: authentications that can continue: publickey,password > debug2: userauth_pubkey_agent: no more keys > debug2: userauth_pubkey_agent: no message sent > debug1: try privkey: /home/bkerin/.ssh/id_dsa > debug3: no such identity: /home/bkerin/.ssh/id_dsa > debug2: we did not send a packet, disable method > debug3: authmethod_lookup password > debug3: remaining preferred: keyboard-interactive > debug3: authmethod_is_enabled password > debug1: next auth method to try is password > fsblk@aurora.uaf.edu's password: > ... > > > Britton Kerin I don't know the fix, but here's some output to compare to in a working scenario: the (slightly munged) command-line: vineet@gobo ~/.ssh % ssh -v -v -v -i id_rsa_test someone@somewhere it's the same as yours until the middle of this block: debug1: got SSH2_MSG_SERVICE_ACCEPT debug1: authentications that can continue: publickey,password debug3: start over, passed a different list publickey,password debug3: preferred publickey,password,keyboard-interactive debug3: authmethod_lookup publickey debug3: remaining preferred: password,keyboard-interactive debug3: authmethod_is_enabled publickey debug1: next auth method to try is publickey debug2: userauth_pubkey_agent: no keys at all debug2: userauth_pubkey_agent: no more keys debug2: userauth_pubkey_agent: no message sent debug1: try privkey: id_rsa_test debug1: read PEM private key done: type RSA debug3: sign_and_send_pubkey debug2: ssh_rsa_sign: done debug2: we sent a publickey packet, wait for reply debug1: ssh-userauth2 successful: method publickey debug1: channel 0: new [client-session] debug1: channel_new: 0 debug1: send channel open 0 debug1: Entering interactive session. ... and continues to a regular successful session Can you get it to work by specifying explicitly the unencrypted private key with -i ? If so, maybe the only issue is telling your ssh where to find its identity file with a statement in the config file. Vineet
Attachment:
pgpKr1Ks8JqnU.pgp
Description: PGP signature