Replication Task doesn't use Dedicated User's SSH key

[nick_]

I'm setting up a replication task between two FreeNAS servers, which I'll call A and B. I've created a dedicated user on both machines, and configured the user's SSH settings on both to allow authentication using a private key from A -> B.

I've figured out all the ZFS permissions and can successfully zfs send and zfs receive from the command line.

Now my problem:

No matter what I specify in the replication task settings, the task tries to use an insecure private key at /data/ssh/replication, and completely ignores the key in the dedicated user's home directory. I say insecure because the key used is stored on the unencrypted boot volume, as opposed to the dedicated user's key which is on an encrypted volume.

Perhaps I'm paranoid, but I'd prefer that if server A is stolen, the thief not be able to remotely log into server B using the easily obtainable key on the boot volume.

Is this a bug? Am I just crazy? Could the key to be used be a task scoped option (this shouldn't break backwards compatibility)?

I've edited /usr/local/www/freenasUI/tools/autorepl.py to use the correct key, but expect this will break every upgrade.

 

[m0nkey_]

I suggest opening a feature request: https://redmine.ixsystems.com/projects/freenas

 

[Ericloewe]

How is the dedicated user's key stored encrypted? FreeNAS has to have the plaintext version to successfully use it, which would mean that the key used to decrypt the key would need to be stored in plaintext. You see where this is going?

Perhaps I'm paranoid, but I'd prefer that if server A is stolen, the thief not be able to remotely log into server B using the easily obtainable key on the boot volume.

You could file a feature request to have all plaintext keys kept in an encrypted database which must be manually unlocked by the user before the server is fully operational. Nothing less is going to solve your problem.

 

[nick_]

How is the dedicated user's key stored encrypted? FreeNAS has to have the plaintext version to successfully use it, which would mean that the key used to decrypt the key would need to be stored in plaintext. You see where this is going?

...

You're entirely right, but this is how encrypted pools work already. The pool can't be mounted after power-off without the geli key and passphrase.

It's kind of obscure, and probably not worth making a supported feature. I was just confused to discover that the "dedicated user" was more about identity used on the remote machine than the local machine. Perhaps if any change is made, it should only be in the documentation.

I ended up making extensive changes to autorepl.py anyway to support resuming sends, large blocks, deduplication, native stream compression, and embedded data. (zfs send -DLec) If it works well I'll clean it up and submit a pull request so the code will be available for reference, if not merged upstream.

 

[Ericloewe]

I ended up making extensive changes to autorepl.py anyway to support resuming sends, large blocks, deduplication, native stream compression, and embedded data. (zfs send -DLec) If it works well I'll clean it up and submit a pull request so the code will be available for reference, if not merged upstream.

Always good to hear!