• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

Automating rsync backups

Sorry for the delay. You need to specify the --rsh option to rsync so that you can pass an extra option to the ssh command. Your line in /mod/var/spool/cron/crontabs/root should look something like this:

Code: 
0 3 * * * /mod/bin/rsync --rsh='/mod/bin/ssh -i /mod/.ssh/id_rsa' -avr --progress --delete --exclude 'Tsr/' mnt/hd2/ root@1.2.3.4:NetBackup/

Replace 1.2.3.4 with the IP address of the NAS..
 
I'm also having trouble with this.
I want to rsync from my hummy box to a linux server, running debian.
I have got this working from windows to the same server, and all is OK so I know the server setup is OK.

What I've done is:
Created a user humax on my server.
On humax box I've created keys:

humax# dropbearkey -t rsa -f /mod/.ssh/id_rsa
Will output 1024 bit rsa secret key to '/mod/.ssh/id_rsa'
Generating key, this may take a while...
Public key portion is:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgm8SLeqlW3CAc945dJ0+REHSzC/mNduRu+Hz19H++Pmem/VXRm1S7+wCqIjREzowV/amnD8Y9/wLW+WHM2O5lBfdysbwblqWvq443A3KuMknjvKVYEtLbJhi9JzNWX/a6VKi+15UxgeizmJtakmsNjM2SxJPQeFQFbLhg220onjbf+k= root@humax
Fingerprint: md5 a7:5f:08:04:bf:b5:3e:06:15:20:a3:a3:0a:aa:d8:b9

I've changed a couple of values above for security reasons.
I then pasted this public key portion into the .ssh/authorized_keys file in the humax user on server.
Directory permissions 700, file perms 600 on both client and server.

When I try to do a simple ssh test from the humax box it fails:
humax# ssh debianlinux date

Host 'debianlinux' is not in the trusted hosts file.
(fingerprint md5 a4:03:67:e2:6e:3f:4d:55:aa:e4:51:85:2d:65:ba:93)
Do you want to continue connecting? (y/n) y

ssh: Connection to root@debianlinux:22 exited: Didn't validate host key

Any ideas?

2 things I have noticed:
1. The fingerprint MD5s above do not match - is that correct?
2. The public key generated is not as long as the public key generated for the windows client. I believe this is due to using a different ssh on the hummy, but does it need converting to make ssh work?

I also checked my sshd_config file on my server and both of those options were already set.

Thanks
 
That error message indicates that the dropbear client doesn't think you pressed 'y' when it asked you to validate the host key.

The fingerprint being shown during connection is from the debian server (its host key) so won't match the key you generated on the humax.

Try:

ssh -y debianlinux date

After the first run the -y can be dropped.
 
Thanks. If I do that it gives:
Host 'debianlinux' key accepted unconditionally
and then prompts for password. If I enter it then the command works.

But... the known_hosts file is NOT being updated and is still 0 bytes so a) the connection doesnt work without the password and b) I still get prompted c) looks like it cannot update the known_hosts file

-rw------- 1 root root 0 Aug 4 10:46 known_hosts

I read something about roots home defaulting to /, but if I look at $HOME it dhows /mod.
Is there an equivilent to truss/strace I can use to check what files it is trying to update?
Or can I update the known_hosts file manually?

Thanks
 
For dropbear's purposes, root's home is /mod so /mod/.ssh is the right directory.
I think you may need to tell dropbear to use key authentication. How about:

Code: 
yes | ssh -i /mod/.ssh/id_rsa debianlinux date
?
 
Right, ignore the above posts about it hanging.
The humax box timed out as I was doing this so I restarted.
What I didn't realise was it clears /dev/hosts on bootup, so it couldn't find my server - hence the hang.

I'm not using IP address instead of hostname

Running the ssh -i has finally created an entry in the known_hosts file and connected

Running without the -i still prompts for the password, so looks like we do need to use that for ssh commands.

Good news is the sync command above is also working.

Many thanks for your help.
 
Glad it's working for you.

If you'd like the hosts entry to persist, you just need to put the lines you want into a file called /mod/etc/hosts and they will be appended to the one that is generated at boot time.

You could also add aliases for the ssh and scp commands to automatically include the -i argument by creating a profile file in /mod/etc/profile/

So, you could put the following into /mod/etc/profile/dropbear
Code: 
humax# alias ssh='ssh -i /mod/.ssh/id_rsa "$@"'
humax# alias scp='scp -i /mod/.ssh/id_rsa "$@"'

then log out and in again.
 
Thanks again, I'll amend the correct hosts file as it will be easier than using IP address in the long run.
Not so bothered about the aliases as its up and running so shouldn't be changing it again.

Thanks again though, I was about to waste a lot of time thinking it was an ssh protocol incompatibility.
 
I've set up my pvr to transfer my recordings to my nas by following these instructions (they are then downscaled so that I can stream them when I am away on holiday). Would upgrading my CFW affect sshd_config and ssh authorized_keys settings?
 
prpr said:
No. Not that either of those filenames is correct on the Humax as it runs dropbear not sshd.
Click to expand...
Doh! I got this wrong, these are the nas files! Anyway it's nice to know that upgrading the CFW won't affect the rsync backup. Thanks.
 
Last edited:
marsha11 said:
Doh! These are the nas files. Anyway it's nice to know that upgrading the CFW won't affect the rsync backup. Thanks.
Click to expand...
Upgrading the CFW certainly won't affect SSH related stuff on the NAS!

I can't imagine why you think changing the Humax's firmware will affect package settings on its disk.
 
After installing the undelete package I couldn't get rsync backups to ignore the [Deleted Items] folder by using the example in post #6. For anyone who may have this problem, this is what worked ... --exclude='\[Deleted Items\]'
 
You must log in or register to reply here.
Back
Top