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

[BRM <bm_witness@yahoo.com>]

----- Original Message ----

> From: "covici@ccs.covici.com" <covici@ccs.covici.com>
> To: gentoo-user@lists.gentoo.org
> Sent: Thu, October 7, 2010 6:21:15 PM
> Subject: Re: [gentoo-user] Copying a file via ssh with no password, keeping the 
>system safe
> 
> Momesso Andrea <momesso.andrea@gmail.com>  wrote:
> 
> > 
> > Quoting 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
> > >
> > >
> > 
> > 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.
> I  think for ssh to work the user needs a valid shell, not nologin, so
> you can't  do both of those suggestions.]

Wouldn't a shell-less account per just provide the ability to use SFTP/SCP?
Those don't require a shell to operate.

You only need a shell if you are going to actually login as a user and do 
something other than a file transfer.

Also, ssh can be run in multiple modes - some of which do not require a shell; 
for example:

ssh someuser@myhost.com /bin/false

will run the command "/bin/false" without initiating a shell. (man ssh for 
details).

$0.02

Ben