Hi,
I have 2 solaris 10 systems that are in a mirrored configuration (primary / secondary) and I’m trying to use rsync via cron to replicate the users home dir. The script connects as a specific user and rsync the home dir using ssh. The problem im running into is that the primary system asked for a password. I went through the steps of creating a public / private key and making sure the authorized_keys file is not group readable, but it doesn’t seem to work. Any suggestions?

Thanks

Maybe look at or post SSH logs. Sometimes keys are transferred and authentication fails (this will be in the logs), and that's when the ssh client falls back on passwords. You might try to disable password authentication completely (in sshd_config).

I cant disable password auth because I have other people using it. Below are the ssh logs

-bash-3.00$ ssh -v -i /home/user/dsa-key server1
Sun_SSH_1.1, SSH protocols 1.5/2.0, OpenSSL 0x0090704f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to server1 [server1] port 22.
debug1: Connection established.
debug1: identity file /home/user/dsa-key type -1
debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.1
debug1: no match: Sun_SSH_1.1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-Sun_SSH_1.1
debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible
Unknown code 0
)
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: Peer sent proposed langtags, ctos: en-CA,en-US,es,es-MX,fr,fr-CA,i-default
debug1: Peer sent proposed langtags, stoc: en-CA,en-US,es,es-MX,fr,fr-CA,i-default
debug1: We proposed langtags, ctos: i-default
debug1: We proposed langtags, stoc: i-default
debug1: Negotiated lang: i-default
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: Remote: Negotiated main locale: C
debug1: Remote: Negotiated messages locale: C
debug1: dh_gen_key: priv key bits set: 131/256
debug1: bits set: 1576/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'server1' is known and matches the RSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:1
debug1: bits set: 1566/3191
debug1: ssh_rsa_verify: signature correct
debug1: newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
debug1: Next authentication method: gssapi-keyex
debug1: Next authentication method: gssapi-with-mic
debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible
Unknown code 0
)
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/dsa-key
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key '/home/user/dsa-key':


If I put in the passphrase it will connect.

Thanks

You have to verify secure permissions all the way up the chain from that authorized_keys file. Make authorized_keys mode 600. Make the DIRECTORY that contains it, .ssh, mode 700. Make the DIRECTORY that contains .ssh, /home/whatever, mode 755 at least.

Also, if you're using OpenSSH and it's set for "Protocol 2" only, then the proper key file is "authorized_keys2". Create a symlink between "authorized_keys" and "authorized_keys2".

You did put the PUBLIC key into authorized_keys, right? Not your private key.

Also, each entry in authorized_keys must be a single long line, no line breaks in the middle of a key specification. You may have accidently introduced line breaks depending on how you cut/pasted/transferred the public key over to authorized keys.

Oh. DUH! I didn't read your second post all the way through (my fault).

You said "If I put in the passphrase it will connect". This is NOT the server asking you for a PASSWORD. This is the client asking you for a PASS PHRASE. These are totally different things. If you don't want to have to enter a pass phrase, your should not specify one when you create your pub/priv key pair. I'm not sure if you can remove a pass phrase from a keypair after creation (maybe you can, maybe you can't). You may have to just regenerate a new keypair and hit only <ENTER> when it asks you for a pass phrase.

Not even for a little while?
A passphrase is different from the password. A passphrase is generally used to protect your private key. The private key is stored in an encrypted file (on the client machine). The passphrase is required to decrypt it. The decrypted key is required to authenticate. So it is protecting you from other people using your computer (e.g., stolen laptop). There are ways to avoid having to type in a passphrase every time you want to ssh/sftp/scp (it's called ssh-agent).

Oh! you beat me to it (i have many tabs open at once, but sometimes I forget to refresh). Anyway, you can find out how to remove a passphrase from a key here.

That worked. Thanks for all of your help.