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