ZFS send piped though pv

Does anyone use ZFS send [source snap] | pv | ssh [target system] ZFS receive [target pool]

I’m getting a slight issue with pv starting the feedback before I can enter the target system password, sometimes causing it to fail auth before transfer starts, especially if I’m slow to type the password.

perhaps I have not set up the keyfile correctly on the target system

I do realise this is probably a niche of a niche…

setup ssh keys… try again?

probably, but not sure if that will work when sending to root@targetip

I am probably mistaken, but the ssh key file I replicate to the target has come from my user home file.

can I send a key for the root account?

ssh-copy-id

1 Like

You can use the ZFS permissions and setup a user who is alowed to e.g. create snapshots (receive) but NOT to delete them (force sending), I use that for sequential backups to my backup server!

I think @nx2l was into it regarding keys.
I had copied the keys across, as per the freenas instructions, but think I might just need to generate a new key file and try again.
Will poke at it this evening after work.

1 Like

You could try using netcat?

This should install the key properly. Then you need to test it by logging in. you might need to specify the keyfile by using the -i parameter.

ssh-copy-id -i ~/.ssh/key_name.pub [email protected]

copied the public key across, no dice.
went to freenas web gui, ensured the key under the user account matched
opened shell, compared ~.ssh/authourised_keys to the id_rsa.pub, which did match, but still didn’t work.
regenerated key and resent, still nope.

rm -r .ssh/, then generated new keys… and Success!
idk what was messed up :man_shrugging:

1 Like

Probably permissions. If the permissions aren’t correct, SSH will refuse to allow a correct key, because tampering could have happened.

1 Like

Probably.
I suspect I was using a ssh key file from a previous build, so permissions may have got messed up when transferring ~/*

1 Like