BackupPC-users

Re: [BackupPC-users] Client initiated backups, input wanted

2008-12-19 22:02:18
Subject: Re: [BackupPC-users] Client initiated backups, input wanted
From: dan <dandenson AT gmail DOT com>
To: "General list for user discussion, questions and support" <backuppc-users AT lists.sourceforge DOT net>
Date: Fri, 19 Dec 2008 20:00:06 -0700
Ideally, we should write LDAP or AD(or both) authentication into the backuppc web interface.  You wouldnt really have to limit access to any users as the hosts file handles restricing users to hosts.  You could put a flag in the directory that a user is a backuppc user and have the authentication check that.  Any user that logged in that was not setup for backups wouldnt see any hosts anyway.

If this was PHP I could do this myself but it is not.





On Fri, Dec 19, 2008 at 1:38 PM, Johan Ehnberg <johan AT ehnberg DOT net> wrote:
John Rouillard wrote:
> On Fri, Dec 19, 2008 at 06:17:14PM +0200, Johan Ehnberg wrote:
>> Jeffrey J. Kosowsky wrote:
>>> Johan Ehnberg wrote at about 16:54:48 +0200 on Friday, December 19, 2008:
>>>  > Also, the other thing the solution has to cover is security. Giving
>>>  > clients passwordless access to the backuppc user is not an alternative
>>>  > for most people, as it would in most cases give full access to
>>>  > all other clients.
>>>
>>> There are a lot of potential solutions here.
>>> An easy one might be to just give clients access to a dummy account
>>> and then use sudo on the backuppc server to allow them to run a fixed
>>> (limited) set of commands as user backuppc -- i.e. allow them to pass
>>> (some or all) server messages to BackupPC
>> That's what I'm doing now, with an easy system to manage per-client keys
>> so that any compromised key can be revoked (and it never was much danger
>> either).
>
> Or use an ssh forced command associated with the key.
>
> So in ~backuppc/.sshauthorized_keys you would have a (single, not
> split like in this example) line like:
>
> command="/tools/BackupPC/bin/triggerbackup user1",no-agent-forwarding,
> no-X11-forwarding,no-port-forwarding
> ssh-rsa AAAAB3Nz...dju4U= user1@his_her_pc
>
> where the ssh-rsa is the public part of user1's private ssh key.
>
> Then use the ssh supplied variables:
>
>   SSH_CONNECTION
>
> to determine which client connected. From man ssh:
>
>   SSH_CONNECTION
>         Identifies the client and server ends of the connection.  The
>         variable contains four space-separated values: client ip-
>         address, client port number, server ip-address and server port
>         number.
>
> Once you have the client ip, map the ip address of the client to the
> hostname (using dns, ...)  and see if user1 has permission to trigger
> the backup for that host.
>

That's interesting. The variable wouldn't work with mobile clients,
however. But automatically prepending restrictions to the authorized
keys is a good idea indeed. Thanks for this point!

If there is any other way to determine who's calling, it could be of
use, so that no-one can start others' backups - not that it hurts but it
could contribute to centralizing the configs in this model. One option
is having each client use its own user on the server, but it's is only
feasible within a single organization. An that would have to be set on
the client anyway.

/johan

--
Johan Ehnberg

Email: johan AT ehnberg DOT net
GSM:   +358503209688
WWW:   http://www.ehnberg.net/johan/

------------------------------------------------------------------------------
_______________________________________________

------------------------------------------------------------------------------
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/