FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 10-07-2010, 04:45 PM
Momesso Andrea
 
Default Copying a file via ssh with no password, keeping the system safe

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.
 
Old 10-07-2010, 05:36 PM
Stroller
 
Default Copying a file via ssh with no password, keeping the system safe

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.
 
Old 10-07-2010, 06:14 PM
Willie Wong
 
Default Copying a file via ssh with no password, keeping the system safe

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
 
Old 10-07-2010, 06:26 PM
Willie Wong
 
Default Copying a file via ssh with no password, keeping the system safe

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
 
Old 10-07-2010, 06:40 PM
Andrea Conti
 
Default Copying a file via ssh with no password, keeping the system safe

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
 
Old 10-07-2010, 09:59 PM
Momesso Andrea
 
Default Copying a file via ssh with no password, keeping the system safe

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.
 
Old 10-07-2010, 10:21 PM
 
Default 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.]

--
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
 
Old 10-07-2010, 10:28 PM
Willie Wong
 
Default Copying a file via ssh with no password, keeping the system safe

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
 
Old 10-07-2010, 10:38 PM
BRM
 
Default Copying a file via ssh with no password, keeping the system safe

----- 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
 
Old 10-08-2010, 08:05 AM
Andrea Conti
 
Default Copying a file via ssh with no password, keeping the system safe

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
 

Thread Tools




All times are GMT. The time now is 07:44 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org