Whenever I reboot my droplet, the keys in the 'authorized_keys' file under /root/.ssh get deleted and a strange, UNKNOWN key, which I never inserted by any method, nor have I seen even in DO control panel, shows there already present. What is peculiar is that in the end of the key, where comment is written, "motherfucker" is written in these letters: "mdrfckr"

I've tried deleting all keys from this file and from my DO control panel and then inserting fresh keys thru DO control panel (thinking that perhaps DO control panel takes precedence and resets the contents of this authorized_keys file at every reboot). But DO control panel keys are there as expected, but they don't seem to have any effect in my logging efforts.

Due to this, every time my droplet reboots, I've to delete this key and insert 2 keys from myself, one ppk key for ftp, and another openssh key for bash terminal. After inserting them, I'm able to work/login normally.

Pls help. Lest there might be some intrusion into my droplet. (DO hasn't replied to my ticket yet, nor do I expect a fast reply from them ever. even their first reply doesn't contain anything useful, and is there just for the sake of that they replied).

  • You should look into the init scripts that are run just after the droplet starts. Depending on the OS they might be located under /etc. One of the scripts/commands might be responsible for the change. Dec 12 '19 at 12:10
  • Which file under /etc? Also, after reboot nginx status shows as 'Failed' but when I 'start' it manually, it gets started (don't know if related or not). Dec 12 '19 at 12:38
  • I checked all sh files under /etc/cron.d. But they're are normal files (I compared them with another healthy/ok droplet). Dec 12 '19 at 12:56
  • The droplet is based on what OS ? If it is a systemd managed you should check on etc/systemd . Also the system might be compromised and you should check if the services exposed - you mentioned nginx - have their binaries safe and from the distro. Dec 12 '19 at 14:38
  • Mine is ubuntu 18.04 on DO. DO support suggested that my OS could have been compromised, but they're not sure. Dec 13 '19 at 12:50

I tried all the solutions given in the comments to Orig Question posted here. But in the end found/decided that its indeed a compromise/infection only.

Then I contacted DO team, and they too confirmed that this behaviour can't be attributed to anything else than an infection/compromise. So, I created a snapshot of the droplet and created a new fresh droplet (didn't reformat the same). And when I restored that old snapshot over new droplet, every thing was fine. Even it was the snapshot of earlier droplet, still the earlier behaviour didn't reoccur, even after so many days (over a month now).

So, if anyone encounters similar problem, he shouldn't worry about installing every thing again on a new/fresh droplet, but he can overwrite the new droplet with the snap shot of the earlier droplet safely.

Not the answer you're looking for? Browse other questions tagged or ask your own question.