1 |
> We're doing the same thing for our backups. Here's that chunk of our |
2 |
> documentation, if it's helpful. |
3 |
|
4 |
Thanks Michael. You've found that a shell account is required on the |
5 |
backup server in order to push backups to it? |
6 |
|
7 |
Is the purpose of the Host block in .ssh/config to store the hostname |
8 |
of the backup server so it doesn't need to be used directly in the |
9 |
rdiff-backup command? |
10 |
|
11 |
Why create a password for the backup user? Doesn't that open up the |
12 |
possibility of someone logging in as that user, when otherwise the |
13 |
account would only be used for backing up files? |
14 |
|
15 |
- Grant |
16 |
|
17 |
|
18 |
> === rdiff-backup Client === |
19 |
> |
20 |
> ==== Creating the Remote User ==== |
21 |
> |
22 |
> First, create a new system user on the backup server. Log in (as root), |
23 |
> and run, |
24 |
> |
25 |
> useradd -d /home/<username> -m <username> |
26 |
> |
27 |
> The ''-d'' parameter sets the home directory, and ''-m'' creates it |
28 |
> automatically. |
29 |
> |
30 |
> The rdiff-backup program uses SSH to synchronize the local and remote |
31 |
> filesystems. As a result, non-interactive operation requires a |
32 |
> server/client certificate pair. Furthermore, we cannot prevent shell |
33 |
> logins for our new user account. |
34 |
> |
35 |
> Give it a reasonably-complex password. You'll only need to type it twice: |
36 |
> |
37 |
> passwd <username> |
38 |
> |
39 |
> ==== Installing rdiff-backup ==== |
40 |
> |
41 |
> First things first; install rdiff-backup on the client. In Gentoo, all |
42 |
> this requires is the following, |
43 |
> |
44 |
> emerge rdiff-backup |
45 |
> |
46 |
> If that works, go ahead and continue. |
47 |
> |
48 |
> ==== Setting up SSH Authentication ==== |
49 |
> |
50 |
> For now, we're done on the backup server. Log in to the client server |
51 |
> (the one to be backed up) as root. We need to generate an SSH key pair: |
52 |
> |
53 |
> ssh-keygen |
54 |
> |
55 |
> Name the file something informative when asked. '''Do not create a |
56 |
> password for the key file.''' For example, your private key for |
57 |
> <backup_server> might be named ~/.ssh/<backup_server>_rsa. Now, copy the |
58 |
> public key, e.g. ~/.ssh/<backup_server>_rsa.pub to the backup server |
59 |
> using the user that we created earlier. |
60 |
> |
61 |
> scp ~/.ssh/<public_key_file> <remote_user>@<backup_server>:~/ |
62 |
> |
63 |
> |
64 |
> And add a section to the local ~/.ssh/config file which corresponds to |
65 |
> the backup server. This forces the local machine to authenticate to the |
66 |
> backup server using its key rather than a password. |
67 |
> |
68 |
> <pre> |
69 |
> Host <backup_server_hostname> |
70 |
> Hostname <backup_server_hostname> |
71 |
> IdentityFile ~/.ssh/<private_key_file> |
72 |
> IdentitiesOnly yes |
73 |
> </pre> |
74 |
> |
75 |
> |
76 |
> Now, ssh into the backup server as your new user. Our goal is to add |
77 |
> this key as "trusted," allowing anyone with the corresponding key to |
78 |
> connect as this user. On the backup server (as our new user), execute, |
79 |
> |
80 |
> cat <public_key_file> >> ~/.ssh/authorized_keys |
81 |
> rm <public_key_file> |
82 |
> |
83 |
> and add the following to the authorized_keys file manually. Add it at |
84 |
> the beginning of the line for the new public key. |
85 |
> |
86 |
> command="/usr/bin/rdiff-backup --server",no-pty,no-port-forwarding |
87 |
> |
88 |
> This will restrict the user with this public key to executing only the |
89 |
> rdiff-server command. |