Locking down ssh commands, while using rsync. - Tools

This is a discussion on Locking down ssh commands, while using rsync. - Tools ; I have a questions regarding the locking down of commands while using rsync. I have two servers, and need to copy a complete filesystem from server "A" to server "B". Because of permission issues on the filesystem, the only way ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Locking down ssh commands, while using rsync.

  1. Locking down ssh commands, while using rsync.

    I have a questions regarding the locking down of commands while using
    rsync.

    I have two servers, and need to copy a complete filesystem from server
    "A" to server "B". Because of permission issues on the filesystem,
    the only way I can figure this out is by creating a null password key
    for root, and copying it over to server "B", and performing an rsync
    as root. I then tried to limit root's access by configuring the
    authorized_keys file with the "from=" and the "command=" options. So
    far so good, the only thing is I can't seem to limit what is being
    copied over to server "B"

    I.E. authorized_keys

    from="host_a.mysite.com",command="/usr/local/bin/validate-rsync"
    ssh-rsa keyinfo


    cat /usr/local/bin/validate-rsync

    #!/bin/sh

    case "$SSH_ORIGINAL_COMMAND" in
    *\&*)
    echo "Rejected"
    ;;
    *\;*)
    echo "Rejected"
    ;;
    rsync\ --server\ -vvlogDtprz\ --delete\ .\ /d00*)
    $SSH_ORIGINAL_COMMAND
    ;;
    *)
    echo "Rejected"
    ;;
    esac



    From "A" server I run:

    rsync -avvz -e ssh --delete /d00/primary host_b.mysite.com:/d00




    This works fine, but the command ("$SSH_ORIGINAL_COMMAND") that is
    executed
    on the other side is: "rsync --server -vvlogDtprz --delete . /d00"
    How can I limit what data is sent. What I am trying to avoid is an
    admin rsyncing the wrong filesystem to the remote host. It seems in
    this configuration the root user can copy any filesystem to
    host_b:/d00, I want to ensure that the only filesystem that may be
    copied is /d00/primary. I will be scripting this rsync, and will
    execute via cron, but I want to ensure that the backup filesystem
    isn't stepped.

    Is there a way to further limit this?

    Is using rsync as a server a better option (can't use now because of
    firewall restrictions)?

    Should I be looking at initiating the rync as root, but push the data
    acrossed as another user (right now we are performing a ufsdump, then
    scping the data across, and the restoring when it is needed)?

  2. Re: Locking down ssh commands, while using rsync.


    "Snoopy_" wrote in message
    news:e71fbf62.0411291303.4a081f2f@posting.google.c om...
    > I have a questions regarding the locking down of commands while using
    > rsync.
    >
    > I have two servers, and need to copy a complete filesystem from server
    > "A" to server "B". Because of permission issues on the filesystem,
    > the only way I can figure this out is by creating a null password key
    > for root, and copying it over to server "B", and performing an rsync
    > as root. I then tried to limit root's access by configuring the
    > authorized_keys file with the "from=" and the "command=" options. So
    > far so good, the only thing is I can't seem to limit what is being
    > copied over to server "B"
    >
    > I.E. authorized_keys
    >
    > from="host_a.mysite.com",command="/usr/local/bin/validate-rsync"
    > ssh-rsa keyinfo
    >
    >
    > cat /usr/local/bin/validate-rsync
    >
    > #!/bin/sh
    >
    > case "$SSH_ORIGINAL_COMMAND" in
    > *\&*)
    > echo "Rejected"
    > ;;
    > *\;*)
    > echo "Rejected"
    > ;;
    > rsync\ --server\ -vvlogDtprz\ --delete\ .\ /d00*)
    > $SSH_ORIGINAL_COMMAND
    > ;;
    > *)
    > echo "Rejected"
    > ;;
    > esac
    >
    >
    >
    > From "A" server I run:
    >
    > rsync -avvz -e ssh --delete /d00/primary host_b.mysite.com:/d00
    >
    >
    >
    >
    > This works fine, but the command ("$SSH_ORIGINAL_COMMAND") that is
    > executed
    > on the other side is: "rsync --server -vvlogDtprz --delete . /d00"
    > How can I limit what data is sent. What I am trying to avoid is an
    > admin rsyncing the wrong filesystem to the remote host. It seems in
    > this configuration the root user can copy any filesystem to
    > host_b:/d00, I want to ensure that the only filesystem that may be
    > copied is /d00/primary. I will be scripting this rsync, and will
    > execute via cron, but I want to ensure that the backup filesystem
    > isn't stepped.
    >
    > Is there a way to further limit this?
    >
    > Is using rsync as a server a better option (can't use now because of
    > firewall restrictions)?


    Probably...
    Your rsync server can restrict what directories are made available to remote
    clients (see rsyncd.conf, especially the path= and "use chroot" options).


    >
    > Should I be looking at initiating the rync as root, but push the data
    > acrossed as another user (right now we are performing a ufsdump, then
    > scping the data across, and the restoring when it is needed)?



    Consider using an ssh tunnel through your firewall from your client to the
    rsyncd service. Intiate rsync by a non-root user on the remote end if you
    wish, but the rsyncd server must run as root to avoid permission problems.

    Alternatively, as you suggest, pipe your ufsdump output through an ssh
    connection to the remote host and deposit the ufsdump file as a non-root
    account. If you setup the public keys right, you can avoid a password
    prompt.

    for example: ufsdump 0f - $FS | ssh -i {IDFILE} someuser@hostB "dd
    of=/home/nonroot/mydumpfile "

    IDFILE= private key for the someuser account you are using for
    the ssh connection (~/.ssh/id_rsa)



+ Reply to Thread