Rebooting can change the IP address. Nothing the end user can do if the router itself wants to change an address. This is why I use my own router and bind IP address to MAC address for the development network. This is how you lock it in.
Routers indirectly remove incoming traffic which is not a reply to something the inside device did not initiate. This is just the nature of a system where several inside devices share the same outside IP address…the router knows a reply to something a specific inside device initiated, but if the outside world initiated an attempt to go to the inside world, then it won’t know which device to route to unless it was manually set up. Some routers (such as Comcast) may automatically pass through broadcast traffic since broadcast does not need to be a response to a specific device.
Is the router yours? Can you enter an admin page and bind a MAC address to a specific IP address? If not, then you will probably need to use either a local terminal or serial console to find the output of “ifconfig” to know for certain if your address is correct.
If you happen to have assigned the IP address to your host PC, then it won’t matter what your Jetson’s IP is, it will always log in from the PC to the PC. You absolutely must have an IP address on your Jetson which is unique and not assigned to the PC itself (the address would be in one of the PC’s subnets, but the address would not be one the PC itself actively considers “its own”).
The file permissions show these files were modified on Dec. 26:
Dec 26 10:42 /etc/ssh/ssh_import_id
Dec 26 10:42 /etc/ssh/ssh_host_rsa_key.pub
Dec 26 10:42 /etc/ssh/ssh_host_rsa_key
Dec 26 10:42 /etc/ssh/ssh_host_ecdsa_key.pub
Dec 26 10:42 /etc/ssh/ssh_host_ecdsa_key
Dec 26 10:42 /etc/ssh/ssh_host_ed25519_key.pub
Dec 26 10:42 /etc/ssh/ssh_host_ed25519_key
Well, it isn’t actually a guarantee of change, but it does say something “touched” those files on that date and time. If there was merely a timestamp change, then your ssh connect would not have detected any change (ssh depends on content, not timestamp). The evidence of timestamp in combination with ssh client being upset says the files creating the host “fingerprint” have changed.
There are reasons why those files might have changed and not be due to malicious reasons, but it would be hard to actually say what the cause is. If your system is behind a router which does not allow and does not forward incoming requests (aside from a response to an outgoing request), then odds are it was something non-malicious (but I’ll say more about that below). If your Jetson was visible to the entire outside world, then it might have indeed been malicious, but most malicious hacks would want to preserve the host fingerprint files, and would not want to change them. Two Jetsons swapping IP address might give the illusion of change.
In terms of isolation from the outside world via a router, consider too that any other computer on the inside which is compromised could be used to defeat any kind of security a router provides. Even so it would be an idiot malicious attacker that changes the host fingerprint keys…purposely making it look like the host was compromised doesn’t have much of a purpose.
There are commands to generate keys. I have never seen normal updates change keys, but if you’ve manually run a command for key generation, then I suppose it is possible to have manually changed them on Dec. 26 at 10:42. Highly unlikely though, it is a bit like tripping on the ice of a sidewalk, sliding over to the nearby convenience store, and then accidentally stumbling and buying a winning lottery ticket. :P
I don’t know if you have your timezone set to local or not, but was there anything you were doing with the Jetson at 10:42 AM on Dec. 26?