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

[Momesso Andrea]

Quoting Andrea Conti <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
>
>

Thank you all for your fast replies, I think I'll use all of your suggestions:

-create an unprivilegied user with no shell access as Stroller and  
Andrea suggested

-I'll setup a passwordless key for this user, only limited to a single  
command, as Willie
suggested

This sounds pretty sane to me.

TopperH
http://topperh.ath.cx

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.