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

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

[Momesso Andrea]

Hi list,

I need to set up a cron job to transfer a file every day from server A  
to server B.

I'd like to do that via ssh and with no user assistance, completely automated.

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.

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?

Thank you in advance for your help.

TopperH
http://topperh.ath.cx

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

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

[Stroller]

On 7 Oct 2010, at 17:45, Momesso Andrea wrote:
> I need to set up a cron job to transfer a file every day from server A to server B.
> 
> I'd like to do that via ssh and with no user assistance, completely automated.
> 
> 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.
> 
> 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 could create a user on server B called backup, a user with very limited permissions and no shell (/bin/false). Thus server A can transfer files to serverb:~backup but if the key is compromised then little else can be done.

Not sure if the user could somehow be run in a chrooted ssh, for better security? I'm not sure what files a new user "backup" would have read-access to by default? If the key is obtained from server A then the attacker could copy files from server B (back to wherever they like), and it might be possible to obtain information about what services are run on that system or otherwise learn vulnerabilities from what could be read. 

Stroller.

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

[Willie Wong]

On Thu, Oct 07, 2010 at 06:45:49PM +0200, Momesso Andrea wrote:
> I need to set up a cron job to transfer a file every day from server A  
> to server B.
> 
> I'd like to do that via ssh and with no user assistance, completely 
> automated.
> 
> 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.
> 
> 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?

In the authorized_keys file, you need to include a specification of
"command=<insert command here>". Which means that on log-in with the
public key, the sshd will execute that command, and any other commands
sent from the machine which originated the connection will not
execute. 

So I'd imagine you can untar with the command at the target, and
instead of scp, use something like

  tar <file> | ssh -i <identity file> user@host

(of course, this still opens up the possibility that a partition gets
filled on your target machine by someone copying random string to it,
but you'd have to live with that). 

(Also, note, I haven't actually tried this method of copying files
myself, so while I'd imagine it'd work, you may need to play around
with it for a bit. What I've done before was to have a shell script
set to run, triggered by a public key login like this.)

See 'man sshd' for more detail.  

HTH, 

W

-- 
Willie W. Wong                                     wwong@math.princeton.edu
Data aequatione quotcunque fluentes quantitae involvente fluxiones invenire 
         et vice versa   ~~~  I. Newton

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

[Willie Wong]

On Thu, Oct 07, 2010 at 02:14:47PM -0400, Willie Wong wrote:
> On Thu, Oct 07, 2010 at 06:45:49PM +0200, Momesso Andrea wrote:
> > I need to set up a cron job to transfer a file every day from server A  
> > to server B.
> > 
> > I'd like to do that via ssh and with no user assistance, completely 
> > automated.
> > 
> > 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.
> > 
> > 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?
> 
> In the authorized_keys file, you need to include a specification of
> "command=<insert command here>". Which means that on log-in with the
> public key, the sshd will execute that command, and any other commands
> sent from the machine which originated the connection will not
> execute. 
> 
> So I'd imagine you can untar with the command at the target, and
> instead of scp, use something like
> 
>   tar <file> | ssh -i <identity file> user@host
> 

These two links may also be helpful:

http://www.debian-administration.org/articles/438
http://sial.org/howto/rsync/

W
-- 
Willie W. Wong                                     wwong@math.princeton.edu
Data aequatione quotcunque fluentes quantitae involvente fluxiones invenire 
         et vice versa   ~~~  I. Newton

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

[Andrea Conti]

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

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

[Momesso Andrea]

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.

TopperH
http://topperh.ath.cx

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

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

[covici]

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.]

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

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

[BRM]

----- 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

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

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 428 bytes --]

On Thu, 7 Oct 2010 15:38:24 -0700 (PDT), BRM wrote:

> > 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.

Yes, and also things like rsync.


-- 
Neil Bothwick

In plumbing, a straight flush is better than a full house.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Willie Wong]

On Thu, Oct 07, 2010 at 08:40:31PM +0200, Andrea Conti wrote:
> > 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.
> 

That's partially false. See my response in this thread. 

W
-- 
Willie W. Wong                                     wwong@math.princeton.edu
Data aequatione quotcunque fluentes quantitae involvente fluxiones invenire 
         et vice versa   ~~~  I. Newton

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

[Andrea Conti]

On 08/10/2010 0:28, Willie Wong wrote:

>> 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.
>>
> 
> That's partially false. See my response in this thread.

Why? SSH can do a lot of things, but when used in the way we're
discussing here it just sets up one or more authenticated and encrypted
channels between two endpoints; ignoring the details, each one of these
roughly acts as a couple of pipes, mutually connecting stdin/stdout of a
pair of processes.

When you ssh to a remote host, the remote host's sshd will run a command
and attach the newly created process to the remote end of the
connection; The name of the command is usually passed by the client, but
can be overridden on the server either through the sshd configuration
files (globally or per-client) or with a per-key 'command' option.

Now, the remote sshd is never sent any information about what is
connected to the local end of the pipe (which is not even known to
ssh!), so there is no way to alter its behavior depending on that.

IOW, nothing in the setup you and I proposed prevents the user from
piping an arbitrary command into ssh (or even using a ssh-invoking
wrapper such as scp or rsync) and getting successfully authenticated on
the server. You are only guaranteed that the server will run tar in
place of whatever remote command the client requests, so that the
connection will break if the client side sends non-tar data.

In my opinion this is quite different from "[allowing] only one single
command from a single cronjob to operate passwordless", but then I might
just be splitting hairs.

andrea

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

[Willie Wong]

On Fri, Oct 08, 2010 at 10:05:50AM +0200, Andrea Conti wrote:
> Now, the remote sshd is never sent any information about what is
> connected to the local end of the pipe (which is not even known to
> ssh!), so there is no way to alter its behavior depending on that.
> 
> IOW, nothing in the setup you and I proposed prevents the user from
> piping an arbitrary command into ssh (or even using a ssh-invoking
> wrapper such as scp or rsync) and getting successfully authenticated on
> the server. You are only guaranteed that the server will run tar in
> place of whatever remote command the client requests, so that the
> connection will break if the client side sends non-tar data.
> 
> In my opinion this is quite different from "[allowing] only one single
> command from a single cronjob to operate passwordless", but then I might
> just be splitting hairs.

Okay, reading your explanation I agree with you on both counts: the
behaviour does not exactly fit the letter of the question, and that
you are splitting hairs because I think the behaviour is good enough
for the spirit of the message. 

Cheers, 

W
-- 
Willie W. Wong                                     wwong@math.princeton.edu
Data aequatione quotcunque fluentes quantitae involvente fluxiones invenire 
         et vice versa   ~~~  I. Newton