I created an id_rsa key in my server with ssh-keygen -b 4096 without a passphrase. I added my id_rsa.pub into .ssh/authorized_keys and downloaded my private id_rsa key into local PC and changed it into a pem file.

I tested the SSH access with my pem file in a terminal and Filezilla SFTP. It worked.

The next morning I realized that I can't access the host by SSH with my pem key. Then I tried to access it without the pem key and happily I could access it.

I checked authorized_keys, it's empty and only one public key left.

I checked /var/log/auth.log, it's empty too. The only log entry was 10 hours old.

The suspect is deleting command history too.

My sites-available in my Nginx config was deleted too. Even my www/ folder is empty.

My MariaDB is uninstalled.

I wonder why the suspect is not deleting my SearX service.

I already configured my firewall too. Here is my firewall access:


  • TCP 80
  • TCP 443
  • TCP (My SSH Port)


  • TCP 80
  • TCP 443
  • UDP 53 (For DNS)

What can I learn from it? What mistake occurred to allow this to happen?

  • 1
    Might you have some automation that manages (and can overwrite) your authorized_keys file? Also: you should generate private keys on the system that will use them, not the system that will use the public key. I do not recommend transferring private keys between computers.
    – Adam Katz
    May 17, 2022 at 14:54
  • @AdamKatz I use scp for transfer my key. I don't know is this safe or not. May 18, 2022 at 1:53
  • 1
    scp itself is plenty secure. The issue is that each system that has had access to a key increases your risk. It should be minor, because presumably you trust that system has not been breached, but it's better to have never exposed the private key to any other system. However, that was a secondary concern. I suspect you have automation that overwrites your authorized_keys file.
    – Adam Katz
    May 18, 2022 at 13:38

1 Answer 1


I suspect either your SSH keys are leaked from somewhere or you might have a vulnerable application hosted on the server that has a remote command execution vulnerability. Couple of things that I'll recommend you to do immediately:

  1. Rotate all the private SSH keys, even the newly created one
  2. Check for any unknown users in /etc/passwd
  3. Restrict SSH from your IP only, reference here.
  4. Check for unknown/malicious connections established via netstat -ano command
  5. Check for malicious cron jobs
  6. If you are hosting anything on the server, you need to audit that as well if there is Remote Command Execution in that application or not.
  7. Monitor the access logs of the application, if present, to detect anomalies.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .