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 <jo...@ehnberg.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= us...@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: jo...@ehnberg.net > GSM: +358503209688 > WWW: http://www.ehnberg.net/johan/ > > > ------------------------------------------------------------------------------ > _______________________________________________ > BackupPC-users mailing list > BackupPC-users@lists.sourceforge.net > List: https://lists.sourceforge.net/lists/listinfo/backuppc-users > Wiki: http://backuppc.wiki.sourceforge.net > Project: http://backuppc.sourceforge.net/ >
------------------------------------------------------------------------------
_______________________________________________ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
