Indeed. In fact, replication and the large copy test do not work on Ubuntu
out-of-the-box, as Ubuntu disables root login. That will happen with many
distributions, too.

Not only do SSH keys have to be shared, but you have to make sure that the hosts have
each other in known_hosts. Otherwise you will get a "Host key verification failure".

"""
root@test-4:~# zumastor define source zumatest10g test-3.localnet -p 60
Host key verification failed.
root@test-4:~# ssh test-3.localnet
The authenticity of host 'test-3.localnet (192.168.0.53)' can't be established.
RSA key fingerprint is 6c:2c:b7:84:37:3c:9d:94:17:58:4d:03:11:5e:dd:9b.
Are you sure you want to continue connecting (yes/no)? yes
root@test-3:~# logout
Connection to test-3.localnet closed.
root@test-4:~# zumastor define source zumatest10g test-3.localnet -p 60
root@test-4:~# 
"""

I've got a solution that everyone should be able to come into agreement with. It is
the exact same way Debian syncs it's mirror network and is dubbed "ssh triggers".
This *does* require root ssh access on the server, but if you are really anal, you
can set a directive in the sshd_config, "PermitRootLogin forced-commands-only". That
only allows ssh triggers.

In the authorized_keys file for /root/.ssh/authorized_keys on the destination you
could put something along the lines of this:
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/usr/bin/zumastor
--verify-ssh-trigger" ssh-dss
AAAAB3NzaC1kc3MAAACBALsy38GnYM1WtJdFo0UG9f4mqFbYaxl7jTmIpNgrPEsZ1v2SLdRlrxFbJHmil4gMUG0ZpkGaM+kjQN77wHvg52eFgCBqCm31Mc5lKcKiZ1O/H9sR4+KbU3ZecXRveKcpu50YIdF44PC1dU3MNWY7Xk591Lzn391yUYNdMnlIuXY5AAAAFQCqo326CDB0RrkEjp9y1yS2OEAoewAAAIBFeYaFEUEHBY7ddL6MQkTMgJvCh0zKx5O87k3tn29mW/B88/DRgW4WGrJqMN83HdWnuUx28b0N5nIOXs6ZCRsQlsd4T0JhmEqo5HWFnFm7DknuAnZJgMvop07S4BQPLUkfe5HkmARJZC2aaZ0FVEcdIljfYeM2R5FiIMobSd1ObwAAAIEAottwLjv8MlCUxiqgM6MxMLKE2lxhoyJLCVSLKSLY9ehIbeATrnw1ak1LENl/vCAhqRo+h+yY6meQHD5qmQBC7Sh6b6mYX2cPZnpM8xgcCt2DXL6pC/HJDuYBldD4rTYInShBb07ET2zBevpHA2vgR5Ri/EjxZcqOwnEy5XrnOVKGU=

Now when you login to the destination with the matching key, "/usr/bin/zumastor
--verify-ssh-trigger" will be ran and have $SSH_ORIGINAL_COMMAND as the actual
command sent.

Here is an example verification script on my personal website:
http://www.digitalprognosis.com/opensource/scripts/ssh-trigger-verify

So my basic idea is to roll something derived from the above script that only allows
commands starting with ^zumastor to run. zumastor could then exec itsself again or
just call the appropriate functions.

In the attachment is a patch that implements Jeff's proposal in zumastor. It adds a
'zumastor remote' command that is to be used as the ssh triggered command. The
command is basically a copy of Jeff's ssh-trigger-verify with small modifications.
Except 'zumastor receive start' and 'zumastor receive done', there are another two
remote executions in the current zumastor code. One is used to check target hostname
on downstream in function replicate_snapshot. I replaced this with a 'zumastor
targethost' command. The other remote execution is used to get the upstream volume
size in function set_source. To support this, I allowed remote execution of ddsnap
commands as well as zumastor commands. I think a better solution is to replace them
with 'zumastor get property' commands, so we only allow remote execution of zumastor
commands.

To try the patch, add
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="zumastor remote"
before the normal ssh key and change set PermitRootLogin to "forced-commands-only" in
sshd_config. Later, we may want to add a special 'zumastor' account for privilege
separation. I think we also would like to control the behavior of the 'zumastor'
account then. So the added code can also be used in that case.

The patch is lightly tested. It passes the cbtb tests. But I did not modify cbtb to
use command ssh keys, so it only means the patch does not break the current code.

zumastor_ssh_control.patch 2.1 KB   Download