Welcome! » Log In » Create A New Profile

Sudo based backup account?

Posted by Anonymous 
Sudo based backup account?
May 15, 2015 08:08PM
Are newer versions of rsnapshot capable of initiating a backup with an
account with password protected sudo so that I can disable remote root
login on servers on the Internet that need to be backed up and easily
limit the privileged commands that can be used?

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
Sudo based backup account?
May 15, 2015 09:11PM
On Fri, May 15, 2015 at 11:07 PM, John Lewis <oflameo2 < at > gmail.com> wrote:
[quote]Are newer versions of rsnapshot capable of initiating a backup with an
account with password protected sudo so that I can disable remote root
login on servers on the Internet that need to be backed up and easily
limit the privileged commands that can be used?
[/quote]
I think you're missing apples and oranges. rsnapshot is normally run
as a root user, in order to allow control of file ownership by the
root operation, and run out of cron. The 'remote root login' is often,
though not always, SSH based. The SSH keys used for secured access can
and, ideally, should be tied through a restricted authorization with
something like the 'validate-rsync.sh' script as a ForceCommand
option, in order to prevent the remote rsync over SSH from doing any
'write' options or other unauthorized changes.

Now, with all that: the rsnapshot server can use an 'ssh-agent', owned
yb the root user and managed with something like the 'keychain' perl
script or any other stored ssh-agent configuration to force password
based access to enable the ssh-agent. This is basically similar to
Apache and other web servers that mandate a user with key credentials
be present to restart the relevant daemon.

Most people don't bother and just use a passphrase key, ideally a
specific key in a non-standard location set asside for just that
reason. But it's certain feasible.

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
Sudo based backup account?
May 15, 2015 10:09PM
On Fri, May 15, 2015 at 11:07:05PM -0400, John Lewis (oflameo2 < at > gmail.com) wrote:

[quote]Are newer versions of rsnapshot capable of initiating a backup with an
account with password protected sudo so that I can disable remote root
login on servers on the Internet that need to be backed up and easily
limit the privileged commands that can be used?
[/quote]
No. In general, sudo is not practical for remote access,
and moreover rsnapshot is generally run non-interactively,
making any kind of password prompting impractical.

If you want to do backups interactively with password
authentication, passphrase-protected rsa keys and
ssh-agent are probably your best bet.

But you can easily limit the commands it can use remotely.

First, you could consider running rsync daemon with
appropriate options in the machines being backed up.
In particular, it can be configured for read-only access:
sufficient for backups without allowing any changes
to be done remotely.
Look at the man page of rsyncd.conf for details.

Second, sshd can be configured to limit what remote
users can do, also selectively by user and host.
E.g., you could specify that root access is only
allowed from your backup machine and then only to
run one specific command.
Take a look at ForceCommand and Match options
in sshd_config man page.

--
Tapani Tarvainen

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
Sudo based backup account?
May 16, 2015 03:37AM
On 05/16/2015 12:48 AM, Tapani Tarvainen wrote:
[quote]On Fri, May 15, 2015 at 11:07:05PM -0400, John Lewis (oflameo2 < at > gmail.com) wrote:

[quote]Are newer versions of rsnapshot capable of initiating a backup with an
account with password protected sudo so that I can disable remote root
login on servers on the Internet that need to be backed up and easily
limit the privileged commands that can be used?
[/quote]No. In general, sudo is not practical for remote access,
and moreover rsnapshot is generally run non-interactively,
making any kind of password prompting impractical.

If you want to do backups interactively with password
authentication, passphrase-protected rsa keys and
ssh-agent are probably your best bet.

But you can easily limit the commands it can use remotely.

First, you could consider running rsync daemon with
appropriate options in the machines being backed up.
In particular, it can be configured for read-only access:
sufficient for backups without allowing any changes
to be done remotely.
Look at the man page of rsyncd.conf for details.

Second, sshd can be configured to limit what remote
users can do, also selectively by user and host.
E.g., you could specify that root access is only
allowed from your backup machine and then only to
run one specific command.
Take a look at ForceCommand and Match options
in sshd_config man page.

[/quote]
I considered using a rsync daemon, but I won't be able to dump databases
remotely doing a backup.

Right now I run a dump via a script that dumps a database to standard
output that I execute over a remote ssh session. Right now the easiest
way to lock things down a bit more is to use ssh keys with restricted
commands, but I would have to write a wrapper script around the database
dump commands and install them on the clients because making bash the
only command executable actually presents a lot of options. Going
without a wrapper would give me a high likely hood of having to
regenerate key pairs every time I need to dump a new kind of database.

If rsnapshot was like ansible and could use sudo, I could store the
password in a shell variable, prevent access without an ssh key, and
limit the commands executed with sudo without needing to develop,
package, and install wrapper scripts.

---

After thinking about it more, generating a new key with more commands
would by far be the easiest and most transparent thing to do, but it may
make configuring the backup harder because I may not be able to store
the backup script in a file different than the rsnapshot job.

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
Sudo based backup account?
May 16, 2015 11:33AM
On Sat, May 16, 2015 at 06:36:20AM -0400, John Lewis (oflameo2 < at > gmail.com) wrote:

[quote]I considered using a rsync daemon, but I won't be able to dump databases
remotely doing a backup.
[/quote]
Not directly, true. You could dump the database to a file and
transfer that, though (using cron or rsyncd's pre-xfer exec),
but you'd need extra disk space in the client for the dump.

[quote]Right now I run a dump via a script that dumps a database to standard
output that I execute over a remote ssh session. Right now the easiest
way to lock things down a bit more is to use ssh keys with restricted
commands, but I would have to write a wrapper script around the database
dump commands and install them on the clients because making bash the
only command executable actually presents a lot of options. Going
without a wrapper would give me a high likely hood of having to
regenerate key pairs every time I need to dump a new kind of database.
[/quote]
Why? I must be missing something here.

I presume there is a reason why you can't use the simple approach of
opening the database to the backup machine and using rsnapshot's
backup_script feature to run mysqldump or pg_dump or whatever
directly?

But doing it over ssh isn't much harder.

It would seem to me all you'd need is to add a new dump user for
each database and allow just the appropriate dump command.
No need for extra keys that I can see.

Alternatively, a bit more complicated wrapper could handle many
different kinds of databases with single user account.

[quote]If rsnapshot was like ansible and could use sudo, I could store the
password in a shell variable, prevent access without an ssh key, and
limit the commands executed with sudo without needing to develop,
package, and install wrapper scripts.
[/quote]
You'd still need to manage custom sudo rules. It isn't obvious to me
why they'd be easier than wrapper scripts. And having passwords in
shell variables is generally less safe than public key authentication.

[quote]After thinking about it more, generating a new key with more commands
[/quote]
I'm confused. How are commands tied to keys?
There must be something in your setup I don't understand.

[quote]would by far be the easiest and most transparent thing to do, but it may
make configuring the backup harder because I may not be able to store
the backup script in a file different than the rsnapshot job.
[/quote]
Why not? And anyway, a single rsnapshot job can use multiple
login accounts and ssh keys, too, if needed.

--
Tapani Tarvainen

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
Sudo based backup account?
May 18, 2015 11:09AM
Here&#39;s a concrete example combining ssh keys with forced commands and Rsnapshot&#39;s preexec directive to dump my Subversion repository and PostgreSQL database before backup.

    ## from rsnapshot config file for serverX. Note that the first whitespace is a tab, the rest are spaces.
    cmd_preexec /usr/bin/ssh -i /root/.ssh/serverX-backup_preexec-key root < at > serverX /root/rsyncdir/backup_preexec

    ## from serverX:/root/.ssh/authorized_keys
    command="/usr/local/bin/backup_preexec" ssh-rsa [redacted public key]

    ## serverX:/usr/local/bin/backup_preexec
    ## This is designed so that the output merges nicely into Rsnapshot&#39;s log,

    ## and failures are kept to a minimum so that backups proceed if feasible.
    #!/bin/sh
    RVAL=0
    echo -n "    serverX svn_backup "
    exec /usr/bin/svnadmin hotcopy --incremental /redacted/path /redacted/path.hotcopy
    EVAL=$?
    if [ $EVAL -ne 0 ]; then
        echo "failed with $EVAL"
        RVAL=1
    else
        echo "completed successfully"
    fi
    echo -n "    serverX pg_backup "
    ## The following is an overly elaborate bash script that manages dump
    ## rotation, the core command is
    ##     su - postgres -c "/usr/bin/pg_dumpall >$BDIR/$BASE.0"
    /usr/local/bin/pg_backup
    EVAL=$?
    #echo "  rval = $EVAL"
    if [ $EVAL -ne 0 ]; then
        echo "failed with $EVAL"
        RVAL=$((RVAL+2))
    else
        echo "completed successfully"
    fi
    return $RVAL

On Sat, May 16, 2015 at 11:32 AM, Tapani Tarvainen <rsnapshot < at > tapanitarvainen.fi ([email]rsnapshot < at > tapanitarvainen.fi[/email])> wrote:
[quote]On Sat, May 16, 2015 at 06:36:20AM -0400, John Lewis (oflameo2 < at > gmail.com ([email]oflameo2 < at > gmail.com[/email])) wrote:

[quote]I considered using a rsync daemon, but I won&#39;t be able to dump databases
remotely doing a backup.
[/quote]
Not directly, true. You could dump the database to a file and
transfer that, though (using cron or rsyncd&#39;s pre-xfer exec),
but you&#39;d need extra disk space in the client for the dump.

[quote]Right now I run a dump via a script that dumps a database to standard
output that I execute over a remote ssh session. Right now the easiest
way to lock things down a bit more is to use ssh keys with restricted
commands, but I would have to write a wrapper script around the database
dump commands and install them on the clients because making bash the
only command executable actually presents a lot of options. Going
without a wrapper would give me a high likely hood of having to
regenerate key pairs every time I need to dump a new kind of database.
[/quote]
Why? I must be missing something here.

I presume there is a reason why you can&#39;t use the simple approach of
opening the database to the backup machine and using rsnapshot&#39;s
backup_script feature to run mysqldump or pg_dump or whatever
directly?

But doing it over ssh isn&#39;t much harder.

It would seem to me all you&#39;d need is to add a new dump user for
each database and allow just the appropriate dump command.
No need for extra keys that I can see.

Alternatively, a bit more complicated wrapper could handle many
different kinds of databases with single user account.

[quote]If rsnapshot was like ansible and could use sudo, I could store the
password in a shell variable, prevent access without an ssh key, and
limit the commands executed with sudo without needing to develop,
package, and install wrapper scripts.
[/quote]
You&#39;d still need to manage custom sudo rules. It isn&#39;t obvious to me
why they&#39;d be easier than wrapper scripts. And having passwords in
shell variables is generally less safe than public key authentication.

[quote]After thinking about it more, generating a new key with more commands
[/quote]
I&#39;m confused. How are commands tied to keys?
There must be something in your setup I don&#39;t understand.

[quote]would by far be the easiest and most transparent thing to do, but it may
make configuring the backup harder because I may not be able to store
the backup script in a file different than the rsnapshot job.
[/quote]
Why not? And anyway, a single rsnapshot job can use multiple
login accounts and ssh keys, too, if needed.

--
Tapani Tarvainen

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
[url=http://ad.doubleclick.net/ddm/clk/290420510;117567292;y]http://ad.doubleclick.net/ddm/clk/290420510;117567292;y[/url]
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net ([email]rsnapshot-discuss < at > lists.sourceforge.net[/email])
[url=https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss]https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss[/url]

[/quote]

--
Paul Mackinney
Systems & Quality Manager
O.N. Diagnostics, LLC
2150 Shattuck Ave. Suite 610, Berkeley, CA 94704
510-204-0688 (phone) | 510-356-4349 (fax)
_____________________________________________
If you receive this message in error, please delete it immediately. This message may contain information that is privileged, confidential and exempt from disclosure and dissemination under applicable law.
Sorry, only registered users may post in this forum.

Click here to login