Re: [gentoo-user] Copying a file via ssh with no password, keeping the system safe

[Andrea Conti <alyf@alyf.net>]

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 root@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 foo@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> foo@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