> 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.
I found this article series from 2002 (!) quite good.
http://www.hackinglinuxexposed.com/articles/20021211
Am 23.09.2013 um 23:58 schrieb m.r...@5-cent.us:
>> 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 yo
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
Lists wrote:
> On 09/23/2013 02:44 PM, m.r...@5-cent.us 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 i
On 09/23/2013 02:44 PM, m.r...@5-cent.us 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
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
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 c
On Mon, Sep 23, 2013 at 3:26 PM, Lists wrote:
> >
> Depending on how you interpret this statement, my documented process may
> present a (mild) improvement.
>
> It has the backup account on the public server being a non-priviliged
> account only able to run a (tightly controlled) shell script whic
On 09/23/2013 01:02 PM, m.r...@5-cent.us wrote:
> It does have to
> run as root, though, on both, to preserve ownership of home and project
> directories, etc.
Depending on how you interpret this statement, my documented process may
present a (mild) improvement.
It has the backup account on the
Lists wrote:
> We've been using rsync since forever to back up all our servers and it's
> worked without a problem. But in a recent security review, we noted that
> our specific rsync backup host is using root keys to access the server,
> meaning that if the keys on the backup server were leaked/co
We've been using rsync since forever to back up all our servers and it's
worked without a problem. But in a recent security review, we noted that
our specific rsync backup host is using root keys to access the server,
meaning that if the keys on the backup server were leaked/compromised in
any
11 matches
Mail list logo
