[Help] BUG REPORT: SSH Host Keys are not persistent after TOS 7 updates

[AES]

Hello TerraMaster Support,
I am reporting a major issue with the update process in TOS 7. Every time I update the firmware, the SSH host keys are being regenerated. This is a critical bug in terms of system administration and security.
After every update, I am blocked from my NAS with this error:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Host key for [IP_ADDRESS]:9222 has changed and you have requested strict checking.
This happens because your update script wipes the /etc/ssh/ directory instead of keeping the unique host identity in a persistent partition. On any normal OS, host keys are generated once during the first installation and never change.
Please fix the update logic so that the SSH identity remains the same across all future firmware versions. It is extremely annoying to manually reset known_hosts on all client machines after every single system patch.

[TMzethar]

I'm sorry you encountered such an exception.
We will confirm the situation you mentioned and fix the error.

[wander1236]

I've been running into this too on my F4-424 Max. Every firmware update changes the host key. It's also a gamble whether the update will reset my Time Machine folder, unrelease ports 80 and 443, and reset a bunch of other settings, too.

[MikeZhang]

Thank you for your feedback and detailed explanation.

We understand the issue you raised. In environments with Strict Host Key Checking enabled, if the SSH Host Key changes after a system upgrade, it can indeed cause clients to display a "REMOTE HOST IDENTIFICATION HAS CHANGED" message and require updating the known_hosts record, which can cause inconvenience for daily management and automated maintenance.

Based on the information you provided, this phenomenon may be related to the SSH Host Key processing mechanism during system upgrades. However, we currently need to further confirm the specific triggering conditions and the design logic of the current version.

We will submit this to the R&D team for further analysis and evaluation, and to confirm whether there is room for optimization in subsequent versions.

Temporary Solution:
Windows: ssh-keygen -R [your NAS IP]:9222
macOS: ssh-keygen -R "[your NAS IP]:9222"

Thank you for your suggestion and feedback. We will continue to monitor this issue and communicate with the R&D team.

[AES]

This is my SECOND COMPLAINT regarding this issue, and I am extremely frustrated.
The problem has NOT been resolved.
Once again, after another routine reboot or system update, my TerraMaster NAS completely wiped and regenerated its internal SSH host keys. As a direct result, my Mac is completely blocked from connecting and throws a critical security warning yet again:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
I have already reported this. SSH host keys MUST remain static across reboots and firmware updates. Your operating system (TOS) keeps destroying them, forcing me to manually purge my known_hosts files on my client machines over and over again just to perform basic tasks. This is a severe bug in how TOS handles network/system restarts.Stop sending me generic replies. Escalate this ticket to your core development team immediately.
When will this critical bug be fixed in an upcoming TOS update?
Provide a permanent workaround right now to stop TOS from wiping these keys on every single reboot.

[EriChan]

Thank you for your continued attention. The issue you reported will be fixed in a subsequent version. Please stay tuned.

[HeliaWu]

Hi there, this issue has been fixed in firmware version 7.0.0765. Feel free to update to the new release.