1 |
On 07/10/2010 18:45, Momesso Andrea wrote: |
2 |
|
3 |
> Setting up a public key, would do the job, but then, all the connections |
4 |
> between the servers would be passwordless, so if server A gets |
5 |
> compromised, also server B is screwed. |
6 |
|
7 |
Well, not really... public key authentication works on a per-user basis, |
8 |
so all you get is that some user with a specific key can log in as some |
9 |
other user of B without typing a password. |
10 |
|
11 |
Of course, if you authorize a given key for logging in as root@B, then |
12 |
what you said is true. But that is a problem with the specific setup. |
13 |
|
14 |
> Is there a way to allow only one single command from a single cronjob to |
15 |
> operate passwordless, while keeping all the other connections secured by |
16 |
> a password? |
17 |
|
18 |
You can't do that on a per-command basis. You'd be trying to control the |
19 |
authentication method accepted by sshd on B according to which command |
20 |
is run on A -- something sshd on B knows nothing about. |
21 |
|
22 |
I would try the following way: |
23 |
|
24 |
- Set up an unprivileged user on B -- let's call it foo -- which can |
25 |
only write to its own home directory, /home/foo. |
26 |
|
27 |
- add the public key you will be using (*) to foo@B's authorized_keys |
28 |
file. You should set the key's options to |
29 |
'pattern="<address_of_A>",no-pty,command="/usr/bin/scp -t -- /home/foo"' |
30 |
(man sshd for details). |
31 |
|
32 |
- chattr +i /home/foo/.ssh/authorized_keys, so that the file can only be |
33 |
changed by a superuser (you can't just chown the file to root as sshd is |
34 |
quite anal about the permissions of the authorized_keys file) |
35 |
|
36 |
Now your cron job on A can do "scp <file> foo@B:/home/foo" without the |
37 |
need for entering a password; you just have to set up another cron job |
38 |
on B that picks up the file from /home/foo and puts it where it should |
39 |
go with the correct permissions, possibly after doing a sanity check on |
40 |
its contents. |
41 |
|
42 |
If you use something else than scp, (e.g. rsync) you should also adjust |
43 |
the command option in the key options above. |
44 |
Note that the option refers to what is run on B, not on A. Also, it is |
45 |
*not* an authorization directive à la /etc/sudoers (i.e., it does not |
46 |
specify what commands the user is allowed to run): it simply overwrites |
47 |
whichever command is requested by the client side of the ssh connection, |
48 |
so that, for example, the client cannot request a shell or do "cat |
49 |
<somefile>". |
50 |
|
51 |
(*) You can either use the key of the user running the cron job on A, or |
52 |
generate a separate key which is only used for the copy operation. In |
53 |
this case, you will need to tell scp the location of the private key |
54 |
file with the -i option. |
55 |
|
56 |
HTH, |
57 |
andrea |