Problem/Justification
When you add a ssh key to the root user for replication from one truenas to another, if the source truenas is compromised it can get to the target truenas using “ssh” to run a shell and/or other commands on the remote truenas as well.
I would like to lock down the ssh key to ONLY allow it to receive the zfs send/receive commands + other zfs command needed to setup/maintain the replication and nothing else.
This can be done by modifying the authorized_keys file to prefix the ssh key with a wrapper script. This script can then sanity check the SSH_CLIENT and SSH_ORIGINAL_COMMAND variables and reject things which are not needed for the zfs replication, once checking has been done it then runs the original command passed via the ssh key session.
Impact
This will dramatically improve security between source and backup target truenas devices meaning that if a source truenas device is compromised it won’t necessarily mean the remote is compromised too.
User Story
I use this feature of ssh to lock down backups in our environment so that rsync over ssh is restricted to just the rsync server and that a compromised server which is a backup client won’t allow access to the remotely hosted backup files (which are stored on snapshotted NFS share from a truenas server).
You could just ensure that your replication user has virtually zero rights to do anything on your source system with the exception of zfs allow send in a PULL configuration.
I did recently write such a “lock down” script for myself. But I only made sure that it works for my use case. It probably only works for one specific set of replication options.
But if anyone is interested in the script, you can check the script here:
