Replication requires CLI action to configure & monitor

[dwhite]

The replication feature requires actions in the CLI to monitor & configure and this should not be necessary. In addition there are some missing features & configuration fields. Permission given to split this ticket into defects & enhancements accordingly.

• The replication authentication public key should be visible from the GUI so it can be copied to and installed in the replicants.
• The GUI should have a function to install public keys for the purposes of receiving replication streams (for situations where FreeNAS is serving as a replicant).
• The /etc/ssh/ssh_known_hosts file is generated with the improper format, rendering it non-functional. Users must still open a root shell, make root writable, then run 'ssh -i /data/ssh/replication replicant' in order to capture the replicant's host key.
• The ssh_known_hosts file seems to contain all host keys ever configured, even if not an active replicant, which is a security vulnerability (or would be if it worked). Compromised host keys cannot be deleted/revoked from the GUI and thus MITM attacks are possible.
• There should be a way to test that the master can communicate successfully with the replicant(s). This test should also verify if the replicant can receive ZFS snapshot streams from the master (i.e., check the stream version).
• The GUI should allow the user to configure what user to log in as on the replicant instead of only using 'root'.
• The GUI should display the last successfully replicated snapshot for each configured replication stream, including the date/time. There is a column for this in the view that is not currently populated.
• Replication configurations should have an Enable/Disable checkbox so replication can be stopped without deconfiguring it (i.e. for replicant maintenance).
• FreeNAS remembers the last snapshot replicated on a particular mountpoint/dataset across replication config deletion, even if the replicant is wiped of all snapshots, which is a POLA violation. FreeNAS should implement either behave consistently on replication creation (i.e., only replicate the latest snap) or provide the user with options as to handle initial replication.

[nixcz]

Also, (I'm not 100% sure about this) it seems like the key(s) are not saved in the database configuration file. If I reinstall a system and restore the configuration file, I still have to set up the keys again manually.