automounting zfs encrypted filesystems

$ zfs set keylocation=file:///etc/some-secret-path dataset/enrypted

And that's all that's needed - well, and a systemctl daemon-reload to actually generate the units. Before that, you can see what zfs-mount-generator plans to do:

$ mkdir /tmp/zfs-gen/
$ /usr/lib/systemd/system-generators/zfs-mount-generator /tmp/zfs-gen/
$ cat /tmp/zfs-gen/zfs-load-key@dataset-enrypted.service
# Automatically generated by zfs-mount-generator

[Unit]
Description=Load ZFS key for dataset/encrypted
SourcePath=/etc/zfs/zfs-list.cache/dataset
Documentation=man:zfs-mount-generator(8)
DefaultDependencies=no
Wants=
After=
RequiresMountsFor='/etc/some-secret-path'

[Service]
Type=oneshot
RemainAfterExit=yes
# This avoids a dependency loop involving systemd-journald.socket if this
# dataset is a parent of the root filesystem.
StandardOutput=null
StandardError=null
ExecStart=/bin/sh -euc '[ "$$(/usr/sbin/zfs get -H -o value keystatus "dataset/encrypted")" = "unavailable" ] || exit 0;exec /usr/sbin/zfs load-key "dataset/encrypted"'
ExecStop=/bin/sh -euc '[ "$$(/usr/sbin/zfs get -H -o value keystatus "dataset/encrypted")" = "available" ] || exit 0;exec /usr/sbin/zfs unload-key "dataset/encrypted"'
~

Which shows that it's just a service that loads the key at startup and unloads the key on shutdown, exactly as you'd want. Note that it also set a mount dependency on the location the key is stored, so that this can be stored on another e.g. another encrypted file system that itself needs to be unlocked.

This all assumes you've done the zfs-zed dance to hook ZFS in to systemd to begin with; if not, the Debian manpage explains how to do that bit.