Backuppc : ssh always ask for password

Discussion in 'Installation/Configuration' started by Trollineto, Jan 17, 2008.

  1. Trollineto

    Trollineto New Member HowtoForge Supporter

    Hello
    I'm trying to backup a linux box (etch) on a backuppc server (etch too) but ssh always ask me for a password.
    I've followed your howto as others (backuppc's faq...), and I don't know where I missed.
    Any Idea ?
    Tx
    Vincent
     
  2. falko

    falko Super Moderator Howtoforge Staff Moderator HowtoForge Supporter ISPConfig Developer

    In the ~/.ssh/authorized_keys2 file on the client, you have something like
    Code:
    from="server1.example.com" ssh-rsa AAAAB3[...]FMZpdAj8Hs9107tZ97Rq2oO/Zw== backuppc@server1.example.com 
    Please remove the
    from="server1.example.com"
    at the beginning. Does it work then?
     
  3. brunus

    brunus New Member

    Hi Falko,
    I have the exact same problem as Trollineto. I've tried your hint, but no success.
    I've gone thru your backuppc 4 times scupolously, with my colleagues controlling me to be sure I didn't make any mistakes or typos, and I end up always with the same issue. Strangely when i did it the first time it worked perfectly, then all of a sudden backuppc stopped working because it can't establish the ssh connection anymore. So i've tried to rebuild the ssh tunnel again, following your instructions on point 5 of your how-to, but no luck. It's like the backuppc server not being able to find the authorized key entry on the client.
    Is there any log I can check to find out the problem?

    thanks

    Paolo
     
  4. brunus

    brunus New Member

    I'm losing my mind on this damn ssh key exchange!
    I've reinstalled both the openssh server and client on both the server and the client to be backed up, config files included. Still, I can't get to have it working.

    Here's is the output of the ssh -vvvv command: please, do help me understand what's wrong.

    thanks,

    paolo

    backuppc@fileserver:~# ssh -l root -vvvv 192.168.1.1 whoami
    OpenSSH_4.6p1 Debian-5ubuntu0.1, OpenSSL 0.9.8e 23 Feb 2007
    debug1: Reading configuration data /etc/ssh/ssh_config
    debug1: Applying options for *
    debug2: ssh_connect: needpriv 0
    debug1: Connecting to 192.168.1.1 [192.168.1.1] port 22.
    debug1: Connection established.
    debug1: permanently_set_uid: 0/0
    debug1: identity file /root/.ssh/identity type -1
    debug3: Not a RSA1 key file /root/.ssh/id_rsa.
    debug2: key_type_from_name: unknown key type '-----BEGIN'
    debug3: key_read: missing keytype
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug2: key_type_from_name: unknown key type '-----END'
    debug3: key_read: missing keytype
    debug1: identity file /root/.ssh/id_rsa type 1
    debug1: identity file /root/.ssh/id_dsa type -1
    debug1: Remote protocol version 2.0, remote software version
    OpenSSH_4.2p1 Debian-7ubuntu3.2
    debug1: match: OpenSSH_4.2p1 Debian-7ubuntu3.2 pat OpenSSH*
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_4.6p1 Debian-5ubuntu0.1
    debug2: fd 3 setting O_NONBLOCK
    debug1: SSH2_MSG_KEXINIT sent
    debug1: SSH2_MSG_KEXINIT received
    debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-
    hellman-group-exchange-sha1,diffie-hellman-group14-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,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
    ,aes128-ctr,aes192-ctr,aes256-ctr
    debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-
    cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
    ,aes128-ctr,aes192-ctr,aes256-ctr
    debug2: 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@openssh.com,zlib
    debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
    debug2: kex_parse_kexinit:
    debug2: kex_parse_kexinit:
    debug2: kex_parse_kexinit: first_kex_follows 0
    debug2: kex_parse_kexinit: reserved 0
    debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-
    hellman-group14-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,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
    ,aes128-ctr,aes192-ctr,aes256-ctr
    debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-
    cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
    ,aes128-ctr,aes192-ctr,aes256-ctr
    debug2: 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@openssh.com
    debug2: kex_parse_kexinit: none,zlib@openssh.com
    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(1024<1024<8192) sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
    debug2: dh_gen_key: priv key bits set: 117/256
    debug2: bits set: 504/1024
    debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
    debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts
    debug3: check_host_in_hostfile: match line 4
    debug1: Host '192.168.1.1' is known and matches the RSA host key.
    debug1: Found key in /root/.ssh/known_hosts:4
    debug2: bits set: 523/1024
    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
    debug2: key: /root/.ssh/identity ((nil))
    debug2: key: /root/.ssh/id_rsa (0x800575b0)
    debug2: key: /root/.ssh/id_dsa ((nil))
    debug1: Authentications that can continue: publickey,password
    debug3: start over, passed a different list publickey,password
    debug3: preferred gssapi-keyex,gssapi-with-
    mic,gssapi,publickey,keyboard-interactive,password
    debug3: authmethod_lookup publickey
    debug3: remaining preferred: keyboard-interactive,password
    debug3: authmethod_is_enabled publickey
    debug1: Next authentication method: publickey
    debug1: Trying private key: /root/.ssh/identity
    debug3: no such identity: /root/.ssh/identity
    debug1: Offering public key: /root/.ssh/id_rsa
    debug3: send_pubkey_test
    debug2: we sent a publickey packet, wait for reply
    debug1: Authentications that can continue: publickey,password
    debug1: Trying private key: /root/.ssh/id_dsa
    debug3: no such identity: /root/.ssh/id_dsa
    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
     
  5. falko

    falko Super Moderator Howtoforge Staff Moderator HowtoForge Supporter ISPConfig Developer

    What's in the ~/.ssh/authorized_keys2 file on the client?
     
  6. brunus

    brunus New Member

    root@efbujagateway:~# cat /root/.ssh/authorized_keys2
    ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA1QqZnL3d4vRGHuz1DI9TmmPaOpeDAfoY1KQdOBuA5frk7xL8jGCKsL/LsPj/+jPsPbNTDelIasXI2ymXvU4m3sgcMsKNeYk9HUKKh4pZc5cR9jNMVpRHuLvpWdz7M2kBRS61j+L/ZgMeVKsnKHwriClmaJv91Z5p16rAkOFB3Cr4+fc3/sgFse/gNqVP+EeAicExfPEbOozr8/sfP+W9MJj37O8nc9glZWyzUtS8mNdQhzEkYqaCqDttXuk3bfwldCeOzU8GifKivDOe/u4S4Ls2xcizHCKLbMjA40a4Cf3mWajYTPCZUE219Q4GCkLdQ60C+u/5vOr5JSFa/xaX/w== backuppc@fileserver
    ssh-dss AAAAB3NzaC1kc3MAAACBALoqHetSNJKsVfNZ5uOtK87VyBEwRmxYwfTk/eCOxWEhmRw0d6JU6OxMSgUsL1gTS6GaiZMUjO9kqPXUDVFR+E1as4pIMscaJz610jEGl1MI6duoyTMHtt5d8ZDlviidH4dANf0BqJ40aq5QlcBUi9M10rEOJNVJFbsqrJThQGOlAAAAFQC7XTPyTlGxCjsgZk2hIgOaktUVUQAAAIEApcDlWXJ9+xDbJ5ScmicDEcUc3oPZn+4KcilwuCUJtjnA3IdPZzvT4grHVEl8UxiAS/ZaxlXsfTdsqSG071WL4aEE3qWIcI5bxvYbQrQA2FjQbwNTid+9bQizAfBjOGWwAD4+Mi6XoBOKC+SVahKCuoUybaW/wI349KDYvxZOwqUAAACBAIxarcDdRLO3zw+bO7orHeSATI/r4kF9bGZLESbTE/4gzMKKb3pitvjaraE5MhhUsmkuj5gakGvtcNTvNYz76lLHLKHtab2LCblIcA6hYbYha6xErx1IUfPTPBNdDxBuNvyQ9PRLqj9o3mYzQmrxIeymVKrl8DYLKppOlbWjEBCG backuppc@fileserver

    I've tried also with ssh-keygen -t dsa, no hope.

    paolo

    PS
    I add that I'm using the client machine (efbujagateway The perfect Ubuntu Server 6.06.1) in recovery mode.
     
    Last edited: Mar 20, 2008
  7. brunus

    brunus New Member

    gotcha!

    Looking at auth.log on my server revealed the problem: sshd was
    refusing to use my public key because my home directory was
    group-writable. In order to do pubkey auth, both the home directory
    and the .ssh directory must writable only by the owner.

    still, my backup restore fails with a Unable to read 4 bytes error :(

    Paolo
     
  8. falko

    falko Super Moderator Howtoforge Staff Moderator HowtoForge Supporter ISPConfig Developer

    On the server or the client?
    Which distribution are you using?
     
  9. brunus

    brunus New Member

    hi,
    as stated earlier, the client is a 'Perfect' Ubuntu Server 6.06.1, called efbujagateway.
    Backuppc is installed on a fileserver.
    When I look at backuppc's error log for efbujagateway, here's what I read:

    efbujagateway
    efbujagateway Accueil Explorer les sauvegardes Fichier journal Fichiers journaux Bilan des derniers transferts échoués Bilan des derniers transferts échoués (erreurs seulement) Modifier la configuration
    Fichier /media/disk/backups/pc/efbujagateway/XferLOG.bad.z (Extraction des erreurs seulement)

    Contenu du fichier /media/disk/backups/pc/efbujagateway/XferLOG.bad.z, modifié le 2008-03-21 04:00:06 (Extraction des erreurs seulement)

    full backup started for directory / (baseline backup #25)
    Running: /usr/bin/ssh -q -x -l root efbujagateway /usr/bin/rsync --server --sender --numeric-ids --perms --owner --group -D --links --hard-links --times --block-size=2048 --recursive --ignore-times . /
    Xfer PIDs are now 28618
    Read EOF: Connection reset by peer
    Tried again: got 0 bytes
    Done: 0 files, 0 bytes
    Got fatal error during xfer (Unable to read 4 bytes)
    Backup aborted (Unable to read 4 bytes)

    and for the restore:

    Fichier /media/disk/backups/pc/efbujagateway/RestoreLOG.12.z (Extraction des erreurs seulement)

    Contenu du fichier /media/disk/backups/pc/efbujagateway/RestoreLOG.12.z, modifié le 2008-03-21 15:58:26 (Extraction des erreurs seulement)

    Running: /usr/bin/ssh -q -x -l root efbujagateway /usr/bin/rsync --server --numeric-ids --perms --owner --group -D --links --hard-links --times --block-size=2048 --relative --ignore-times --recursive . /
    Xfer PIDs are now 15583
    Read EOF: Connection reset by peer
    Tried again: got 0 bytes
    Done: 0 files, 0 bytes
    restore failed: Unable to read 4 bytes

    I repeat that the client machine is running in recovery mode, because permissions have been accidentally screwed up (sudo chmod 777 / ).
    Plus I'm wondering whether some needed services are off and should be on.

    paolo
     
    Last edited: Mar 21, 2008
  10. brunus

    brunus New Member

    SOLVED!

    Sorry Falko,
    with all this mess with ssh, I had still to readd once more the client to the backuppc server known_hosts file. Once it done, it started working again.

    thanks,

    Paolo
     
  11. brunus

    brunus New Member

    I've called it a victory too early!

    i've restored the entire / in the target machine, which means even the /root/.ssh folders, which led to an unmatching couple of ssh-rsa keys, and consequently the backup is not working after the restore.

    I've successfully created 2 new ssh-rsa keys, following your tutorial, and now I get to log password-less as backuppc becoming root:
    $ ssh -l root 192.168.1.1 whoami
    $ root

    Nonetheless, I get the same hideous error:
    Running: /usr/bin/ssh -q -x -l root efbujagateway /usr/bin/rsync --server --numeric-ids --perms --owner --group -D --links --hard-links --times --block-size=2048 --relative --ignore-times --recursive . /
    Xfer PIDs are now 15583
    Read EOF: Connection reset by peer
    Tried again: got 0 bytes
    Done: 0 files, 0 bytes
    restore failed: Unable to read 4 bytes

    I really don't see how I can troubleshoot this any further :(
    Where should I look? Which logs?

    thanks,

    Paolo
     
  12. brunus

    brunus New Member

    Ok, back on again.
    Apparently the problem resides on the fact that despite the backuppc server asks for a machine fingerprint when connecting for the first time to the target machine when doing the ssh-rsa key exchange via scp, this is not enough. In fact, I've tried a manual dump as suggested in the backuppc troubleshooting hits, and ssh did ask once more to add the client's fingerprint to known_hosts before performing the dump. After that, everything started to work normally again.

    paolo
     

Share This Page