Thursday, December 16, 2004

ssh Without a Password

Okay, I have access to another box. I can ssh into it, but it requires a password, so I copy id_dsa.pub to server, put it in a .ssh dir, rename it to authorized_keys, but ssh still requires password; ssh -vvv says:

debug1: Offering public key: /home/djaquay/.ssh/id_dsa

debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply


then a delay, then:

debug1: Authentications that can continue: publickey,gssapi-with-mic,password

debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password


I'm not sure what that "debug2: we did not send a packet" means, especially as the earlier debug2 says "we sent", (past tense). I've verified the authorized_keys in ~/.ssh, and it looks fine. I vaguely remember something like this happening a while back, but don't recall how i solved it (should have blogged it then; will blog it now).

I changed sshd_config on host to only use protocol 2, and uncommented the 'PubkeyAuthentication yes' and 'AuthorizedKeysFile .ssh/authorized_keys' lines, to no avail.

Odd thing: doing '/etc/init.d/sshd restart' doesn't drop my current connection; ah, it forks the process for each connection, so it restarts the main process, making new connections off the restarted one. I drop my own connection after doing each restart.

Talked to my network guy after suspecting that my box didn't have a proper name or DNS entry; he fixed that, and now there's no delay before being asked for my password.

Finally broke down and Googled for that "we did not send a packet" message, and voila (as they say in France), up turned a message on the SecurityFocus forum saying that my .ssh directory and authorized_keys file must both not be group or world writeable; both were, and once fixed, no password was required.

0 Comments:

Post a Comment

<< Home