Hi,
i always considered key-based ssh access to remote systems a security hole. At least i would expect a passphrase for the private key. I do understand that a) even for key based ssh access there are valid use cases and b) for replication automation, not having it somehow breaks the whole idea.
Are there any best practices to use keypairs with password?
I am strongly considering doing selective manual replication via shell and zfs send/recv.
Thanks a lot for any hint ir feedbaück!
rotate your ssh keys - remove old keys and replace with new keys - how often as often as needed… don’t keep your keys old.
that’s a good practice if you use keypairs, but it does not mitigate the possibility to jump very easy from one system to another.
Why is that?
it’s quite obvious, isn’t it? An attacker who gains access to your system which has keypair authentication setup to other servers can access all those servers without having to pass another obstacle. Even though ssh key-based authentication with modern ssh and proper ciphers counts as secure, this is an unnecessary widening of a potential hole once you breached a perimeter.
For example, let’s assume you setup your main TrueNAS box to use replication to one internal TrueNAS backup unit and to one offsite backup, all using ssh keypairs. You think, you follow best practices and properly secured your storage device. But whoever gains access to your main TrueNAS box can also invalidate your replica, no snapshot will prevent it because he automatically has the same user permissions as the ssh user setup for remote login. All without having anything more to do than to attack one box.
Well, if an attacker (who gained access to your main truenas box) is sophisticated enough to also breach other machines with the saved keys, we can also assume that he is sophisticated enough to keylog your passphrases.
I mean, while it possibly adds some thin layer of security, you were already doomed at the moment he gained access to the machine.
The only issue that still bugs me is whether truenas saves the keys inside the boot pool or inside the (preferably encrypted) data pool.
May be, here you are looking at the issue from the wrong angle.
It’s not the key access that you need to limit, but the access to the account that uses the key for replication.
May be I missed something from your original concerns. But just give this a thought, if it helps.
Thanks
The above is good advice. In addition (talking ssh generally and not specific to this use case), you can also configure the receiving side to limit the commands that a particular key pair is permitted to run. This generally mitigates against using a machine as a jump point.
