Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

if created a keyfile for my user to sync two linux server via a cronjob and rsync but right now I've got a problem.

I'm using a keyfile but i don't get no errors on connect but its still prompting me for the password.

My command is: rsync -aun -e "ssh -i /kunden/343193_51373/.ssh/authorized_keys/id_rsa.pub" user@host:/kunden/343194_51373/webseiten /kunden/343193_51373/webseiten

i hope you know the problem and got a solution for this without the need of root rights :)

greetings, Frederick

EDIT: SHH -v Log:

ssh -v -i /kunden/343193_51373/.ssh/identity -l  user host

OpenSSH_5.8p1-hpn13v10, OpenSSL 1.0.0e 6 Sep 2011
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to xxxxxxxx [xxxxxxxx] port 22.
debug1: Connection established.
debug1: identity file /kunden/343193_51373/.ssh/identity type 0
debug1: identity file /kunden/343193_51373/.ssh/identity-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p1-hpn13v10
debug1: match: OpenSSH_5.8p1-hpn13v10 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.8p1-hpn13v10
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: AUTH STATE IS 0
debug1: REQUESTED ENC.NAME is 'aes128-ctr'
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: REQUESTED ENC.NAME is 'aes128-ctr'
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: RSA 22:72:XXXXXXXXXXXXX:84:5f:d4:5b:11:0d
debug1: Host 'xxxxxxxxxx' is known and matches the RSA host key.
debug1: Found key in /kunden/343193_51373/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Next authentication method: keyboard-interactive
share|improve this question
    
do you have any updates? –  Jonathan Dec 12 '11 at 15:26

2 Answers 2

up vote 4 down vote accepted

ssh -i /path/to/private/key is the correct syntax. You are using you're public key... this will not work!

Appart from that. Are you sure you're setup is correct... I'm not aware that authorized_keys can be a folder! See http://sshkeychain.sourceforge.net/mirrors/SSH-with-Keys-HOWTO/SSH-with-Keys-HOWTO-4.html for a complete tutorial. Or if you prefer one in German http://www.huschi.net/14_141_de-howto-secure-shell-ssh-public-key-authentication.html

Also check you're key permissions. private key should have 600. Same applies for the authorized_keys file.

To debug, you should start of with plain ssh... you might need to add an user to the ssh command.

edit:

how have you created your ssh keys? open them with a texteditor and verify they look correct. A private key should start with:

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,C9C5C0756A407FEA7D4747283FDFA526

a public key looks like:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC1EELjEjoKrVSQo30z+QvFffKpCKEZ6LbiwE3kHJs15QH1dG3Axs5IxbBKa/eOf9QTMEhLg6cAp/bBXd+/PBMk9JLWyCkhiDowcQBVL29HA4DEgmzpAShIkoEzUk+cFAL2Iqn7U9YfZMfQaaPaqPzaDml8xeH/xNFEovkinof39Ulpr5g5ihdyoTXPBs48Y9oH2/G+GAc3pc5jaEgP52CjMVfoSUNviBd13Ol8tqauCHFSD0z4m7Gmwh20JtiOzMlD/Jv9+7OILQrIA5oBEmh0Vk++hhdhebTvAI/NMG/N2o0DPrGdsUkg3igMYlO7/noAw56Nd+BBWzpOiaeosNhd jonathan@hostname

verify authorized_keys on the server contains the public key in one line.

share|improve this answer
    
the chmods seem to be right and i tried different types of ssh keys (SSH1-Key with ssh1; SSH1-Key with OpenSSH; SSH2-Key with OpenSSH) but I've got the same problem with all of these. is there away to get more debug data by rsync to see why the key file is rejected? –  Frederick Behrends Dec 8 '11 at 11:04
    
Try just doing a plain ssh connection to the remote server: ssh -vvv user@host. But @Jonathan is correct, you need to use the private key, not the public key and also make sure the authorized_keys file (should not be a directory) on the remote host is correct. –  James O'Gorman Dec 8 '11 at 11:07
    
(to slow) just try this ssh -l remote-user -i /path/to/private/key remote-host. If it works continue to rsync... if not fix ssh first. otherwise rsync will never work with ssh keys. –  Jonathan Dec 8 '11 at 11:08
    
okay right now i create the authorized_keys file like its mentioned in huschi.net/… and tried to log in vie plain ssh with -vvv if got a lot of debug information but cant find the problem in it. what do i have to look for? sorry, i'm no linux pro and im just starting with "simple" tasks on our new servers –  Frederick Behrends Dec 8 '11 at 11:25
    
added the output to my post above –  Frederick Behrends Dec 8 '11 at 12:31

How do I change my private key passphrase?

And don't specify a new password. SSH will then connect without prompting you.

Superuser rights have nothing to do with needing to decrypt the SSH private key, actually. Even if you were running the script as root, you would still need to decrypt the private key if you've password protected it.

share|improve this answer
    
there is no passphrase set but its still prompting me and if i enter the ssh-password it connects and works. seems to be a fallback to "normal login" –  Frederick Behrends Dec 8 '11 at 10:53
    
Ah, OK, you mean it's prompting you for the unix login, not the ssh passphrase? In that case, with the other Answer, you should turn on "-v" as an ssh option to see if it's finding the key correctly. You will also need to look at the server's sshd logs (this will be /var/log/messages or /var/log/auth.log, or something like that). If the server is rejecting your ssh key, then the reason will be in the server-side log. Usually, it has to do with permissions on the ~/.ssh directory or possibly with a malformed authorized_keys file. –  cjc Dec 8 '11 at 11:54
    
Added the output to my post above –  Frederick Behrends Dec 8 '11 at 12:31
    
It looks like the key was correctly used by your ssh client. Your next step is to see the server logs to see why the server is rejecting the key. –  cjc Dec 8 '11 at 12:34
    
i've found /var/log/messages but i have no access to read this file :( –  Frederick Behrends Dec 8 '11 at 12:43

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.