Suspicious backdoor to TrueNAS system (Update: Not a backdoor)

Hi ALL!

I found in the TrueNAS SCALE settings in the Backup Credentials section a key for SSH Connection for admin user
I assume that this is somehow related to the replication task between the two systems. However, I believe that this is a potential backdoor into my system with entry using this key.
Can you explain the need for this key? Who and how enters with this key? What will happen if I delete this key?

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCweGUq9FFbec+iJuv0j9S9ldt6HEzgGgeDsORGVZlUgIAAi25vAC95V9eUOElH0hJN+c9FJBXuf4NgYyX+VmL4Pfoel/Zr1Nng7Hbqzof+Mdv4xsmBA4joRmtoENHI3w69/g1vIohezQfsDRaG+KIxVAP7wYbsro6Kmwx91sZRmaG1N08Xttef/kB0wVMmzdV15wUdEp2DUS0BQT64v03lsnpbsmUuao3VS5gkWBvxVUNMON45ImRLtqWA09ynr4Jg4hDJKx9/a1/M0EfNmaz8YCheo5RO5cqGolBQBLirhTOBXRoOBzWGaQ09Qi53iwP2F+3yNxCCcC5xCKv3yXbLdcMN6EEdaWVOPtjkBvCK85LTUTwmPktT4cyzl5UK5BdpPA/kXFni3dnd4hEdB1pscVdpYDL0V46/SHmRTdjifuHdOdRarD3mJV7QY0jx6362LiOzXZRUaEffHUZCseejF678t2+jpUp3Wlpg0QK5XkLogGfEf6S8RJqVepiyYQ0= root@tnsbuilds01.tn.ixsystems.net
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBAm6N9NW5pS0AZueVbCmseqOMtITFh05u1YLOm4DF5gH7U7Ge1SC7UVzHdtYcN9rIFF+pKQAq/lSnRv3bmWR7+0= root@tnsbuilds01.tn.ixsystems.net
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHn3F6zaS4rySgi15rMmOz4blJAvstvjEMYNTWoKnVQy root@tnsbuilds01.tn.ixsystems.net

That’s exactly what it is. Replication happens over SSH.

The other system that’s replicating to this one enters via SSH.

Replication will stop working.

1 Like

I understand this intuitively, but what confuses me is that these keys are not generated by my system, but are provided from outside!

During replication setup, the system generated new keys to access the remote system and these keys were added to Authorized Keys on the remote side. What are THESE KEYS for root@tnsbuilds01.tn.ixsystems.net ?

No idea. Where are you seeing them, exactly?

I use my NAS for replication, and the only SSH keypairs that I’m seeing under Credentials → Backup Credentials are the ones I added there, and none of them have a reference to root@tnsbuilds01.tn.ixsystems.net. So these keys aren’t there by default, and they aren’t (necessarily, anyway) added when you add a replication target. The question then remains what happened on your system. My suspicion is that they were generated on one of your systems, which for some reason thinks it’s called tnsbuilds01.tn.ixsystems.net, but why it would think that is unclear.

Hey @Dmitriy_Rogozinskiy

What version of SCALE are you running?

OS Version:TrueNAS-SCALE-24.04.2.1

I have two identical systems that replicate data to each other. The problematic keys were added to the Credentials → Backup Credentials → SSH Connections section after setting up replication. These keys are not in the SSH Kaipairs on both systems.

SSH Connections-> Remote Host Key for ADMIN user on the remote system which will be used to login via SSH:


SSH Kaipairs public key:
2024-09-16_09-25-33

PS: But tnsbuilds01.tn.ixsystems.net keys are missing in the SSH server itself. Therefore these keys cannot be used to SSH connect. So I don’t know where else these keys can be used.

I’m hoping someone will be able to provide an answer to that question. Security is the main reason to use TrueNas

There’s honestly nothing to this. It’s not a back door. You can look at the host keys of a given truenas system by cat /etc/ssh/*.pub. They are randomized on TrueNAS install.

2 Likes

Hey @Dmitriy_Rogozinskiy

Thanks for your patience. The hostname you’re seeing at the end of the host key is actually a comment - so there’s no actual connection to these build system hostnames. If you click the Discover Remove Host Key option when editing the SSH connection, you’ll notice that the SSH keys remain the same but the comment disappears.

The reason that the comment has a hostname with an internal ixsystems name is because the keys are initially generated during install-time - at which point we don’t know what your system’s actual hostname will be, so it inherits the name of the system used to compile that given build. We understand that this could cause confusion, so we’re investigating to see why these comments are being added, since ultimately they aren’t necessary to facilitate an SSH connection.

5 Likes

These keys are displayed with these names because these keys are GENERATED with these names.

Future fresh installs will have the comment “root@localhost” instead to make it less confusing to end-users, but there are no plans to replace with the system host name or strip the comment.

2 Likes