When does the host key change?

I am using rclone serve as a gateway to my cloud storage and it has been working flawlessly for months. But recently, I suddenly couldn't connect to the sftp server anymore because the sftp client complained that handshake failed: The host key for '192.168.1.4:2022' has changed. All I had to do tp get it to work again was remove the old key from the known_hosts file.

Not a big deal, but this makes me wonder: under what circumstances does the host key change?

I apologise if this is not even something that rclone controls, but if it is rclone that generates that key, what might have happened that triggered it to regenerate it?

Rclone generates the host key and stores it in the cache directory - see rclone config paths for its location.

On Linux this would be in /home/USER/.cache/rclone/serve-sftp/

So if these files got deleted then rclone would remake them.

And it will do so under those circumstance only? I have no idea how or why those files might have gotten deleted, but I'd assume it would have been connected to some system update (debian 11). But it seems strange that apt would interfere with rclone in that way...

linux repositories, in general, uses an old version of rclone.

can get latest rclone is at
https://rclone.org/downloads/#script-download-and-install

or depending on the current rclone version.
rclone selfupdate

If apt removes or updates something, it generally warns you, tells you about it.

It would be very unlikely that apt removed files from the .cache directory

It's more likely someone deleted it / removed it by mistake or didn't copy it over if it's a new install as folks would miss copying the hidden .cache directory.

For me as an example.

felix@gemini:~$ rclone config paths
Config file: /opt/rclone/rclone.conf
Cache dir:   /home/felix/.cache/rclone
Temp dir:    /tmp

I store nothing in .cache as I override that elsewhere on the mount commands and if I recover something, I never restore back my .cache folder for my home directory.