A couple of weeks ago I found this breakdown of various approaches
https://techstdout.boum.org/EncryptedBackupsForParanoiacs/
We're currently using a variation of the push-backup system described
(using rsync via duplicity).
K
Kahlil (Kal) Hodgson GPG: C9A02289
Head of Technology (m) +61 (0) 4 2573 0382
DealMax Pty Ltd (w) +61 (0) 3 9008 5281
Suite 1415
401 Docklands Drive
Docklands VIC 3008 Australia
"All parts should go together without forcing. You must remember that
the parts you are reassembling were disassembled by you. Therefore,
if you can't get them together again, there must be a reason. By all
means, do not use a hammer." -- IBM maintenance manual, 1925
On Tue, Sep 24, 2013 at 7:58 AM, <m.roth@xxxxxxxxx> wrote:
> Lists wrote:
>> On 09/23/2013 02:44 PM, m.roth@xxxxxxxxx wrote:
>>> Lists wrote:
>>>> On 09/23/2013 01:50 PM, Les Mikesell wrote:
>>>>> Is there something that convinces you that sudo is better at handling
>>>>> the command restriction than sshd would be?
>>>> In the context of a production server, the idea is to remove any
>>>> ability from another host (EG: backup server) to run local arbitrary
> code or
>>>> change local files. (read-only)
>>> <snip>
>>>> You can disable the password on the backup account to achieve a similar
>>>> effect using an SSHD option. If there's a better/simpler way to do this
>>>> via SSHD option I'd love to hear about it!
>>>>
>>> Sure. You disable password authentication, and allow keys only, in
>>> /etc/ssh/sshd_config.
>>
>> This prohibits SSH logins via password, but does not strictly enforce
>> what commands are allowed to be run (and all options allowed) by a
>> specific which is what I was looking for.
>>
>> Having done a bit more research, It does appear that you could use the
>> "ForceCommand" option and disable passwords altogether for a user to
>> achieve a similar effect with SSHD.
>
> Right, but a) it very much limits who can get in. Another thing is that
> you can run the backups from a cron job as a push, instead of a pull.
>
> And the other user still leaves the issue of ownership - only root can
> copy a user's home directory, or a project directory owned by that
> project, and keep it all the same.
>
> And don't forget to save selinux contexts....
>
> mark
>
> _______________________________________________
> CentOS mailing list
> CentOS@xxxxxxxxxx
> http://lists.centos.org/mailman/listinfo/centos
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
