I'm trying to establish rsa key authentication for ssh between 2 boxes as a test before I include more machines. After following procedure listed below, an ssh from local to remote box prompted for a password. After procedure, only files in local:$HOME/.ssh are identity and identity.pub. Only files in remote:$HOME/.ssh are known_hosts and authorized_keys.

> set up identically named accounts on both machines.

> ssh-keygen -t rsa1 on local box. entered null passphrase for test run. entered null passphrase again. ID saved in $HOME/.ssh/identity and public key saved in $HOME/.ssh/identity.pub

> since remote $HOME/.ssh/authorized_keys file did not exist, scp'ed local $HOME/.ssh/identity.pub to remote:$HOME/.ssh/authorized_keys

> chmod'ed remote:$HOME/.ssh/ directory to 755

> chmod'ed remote:$HOME/.ssh/authorized_keys file to 644

I tried an "ssh -vv" for verbosity and got this. Actually this is the tail end of the output. Can anyone decipher why the authentication fell apart? Is it that the public key on the remote machine is errant?

debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.sedebug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.sedebug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 118/256
debug2: bits set: 1584/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host n is known and matches the RSA host key.
debug1: Found key in ~/.ssh/known_hosts:1
debug2: bits set: 1586/3191
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug2: userauth_pubkey_agent: no keys at all
debug2: userauth_pubkey_agent: no more keys
debug2: userauth_pubkey_agent: no message sent
debug1: Trying private key: ~/.ssh/id_rsa
debug1: Trying private key: ~/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug1: Next authentication method: password

Not sure about the problem, but go Dothan, AL! I use to live there years ago. I remember fondly the peanut festival, the golden peanut, Ross Clarke Circle. Ahh, the memories. Never thought I'd see someone else from there.

The Peanut Festival is still great. Traffic on the Circle is worse! How long since you left Dothan? Where are you in VA? I've spent a lot of time in the Norfolk, Newport News, Williamsburg area. I like that a lot.

Here on my system, the authorization file is authorized_keys and permission is set to 400.

You could stop sshd and then start it with debug turned on like

sshd -d -d -d

and see what it reports when you try to connect.

jdarren, the remote file should be "authorized_keys" not users unless specified that way on the remote system config. You might want to take a look at:
http://www.linuxquestions.org/questi...ticle&artid=79

jdarren,

When you edit a posting to the degree which you have done above, you loose the whole context in which the replies were made. As such, it is hard to determine if you, in fact, tried the suggestions that were made below it.

Have you?

Yeah, that edit confused things a bit.

The 2 suggestions to rename ~/.ssh/authorized_users to authorized_keys were dead-on valid, but the problem persists.

I worked through the help topic posted by david_ross, but the problem persists.

I'm currently pulled away on another aspect of the task, but will return. Thanks for the help, guys.

Try checking the file and directory permissions.

On local machine, permissions are:

~/.ssh/ = drwx------

~/.ssh/identity = -rw-------
~/.ssh/identity.pub = -rw-r-----
~/.ssh/known_hosts = -rw-r----

On remote machine, permissions are:

~/.ssh/ = drwxr-xr-x

~/.ssh/authorized keys = -rw-r--r--
~/.ssh/known_hosts = -rw-r--r--

Anyone see problems?

As I said above, your permissions on the authorized_keys file need to be 400 as in: -r--------

I think if you would have followed the "sshd -d -d -d" advice above, it will tell you that.

Permissions on authorized_keys of 400 does not do the trick. I also tried permissions set at other levels as suggested in various procedures I found for ssh. Still no luck.

Post the information that comes from sshd -d -d -d when you try to connect.

Check permissions of your home directory too.

If they are set too loosely ssh will not let you in.

In my case the permissions of my home directory were set too loosely, setting to drwxr-xr-x solved the problem. Thanks.

Also, maybe post your /etc/ssh/sshd_config