SSH intrusion emergency kit for your servers

Disclaimer :

I have no formal training in cybersecurity.
This article is based on my research and hands-on experience.

---

In a previous article, I explained how to * monitor SSH connections* on your server in real time.
A few days after setting up this monitoring on my servers, I received an alert… Even though it was most likely a false alarm (because you’re more likely to find issues when you start looking), I still asked myself:

Ok, how should I react in case of an intrusion?

This article is a checklist of checks and actions to verify whether the connection is authorized and act if it isn’t.

---

1. Check that an SSH connection is actually active

Before panicking, try to confirm the facts.

See connected users

w

This command shows:

• connected users
• their IP address
• their TTY (pts/0, pts/1, etc.)
• how long the session has been active

If you see an unknown user or IP, take note of the TTY.

---

See active SSH network connections

⚠️ Warning: a connection in this list doesn’t mean someone is logged in, it means a connection was established, even if authentication failed.

ss -tnp | grep ':22'

Or, on older systems, use netstat -tnp | grep ssh

---

Inspect SSH logs

Logs show the history of connection attempts.

sudo tail -f /var/log/auth.log -n 1000

For the last 1000 lines or if you’re looking for a specific IP address, run cat /var/log/auth.log | grep <IP address>

---

2. See what the connected user is doing

You can inspect running processes and filter them by user.

htop

Filter them with the u key.

To see files modified in the last 10 minutes, use find:

find /etc /home -type f -mmin -10

---

3. Immediately close the SSH connection

If you want to disconnect the user, take the TTY from the w command and run:

sudo pkill -f <pts/#>

---

4. Understand how access was obtained and prevent reconnection

1. Identify the authentication method in the logs: in /var/log/auth.log look for Accepted password or Accepted publickey
2. If password authentication (Accepted password), follow the password-disabling procedure in the next section.
3. If SSH key authentication (Accepted publickey)
   • List the allowed fingerprints to understand which key the intruder used:
     • ssh-keygen -lf ~/.ssh/authorized_keys
   • Compare with the signature seen in the logs.
   • If the key is known, it was probably compromised

---

5. Disable password authentication

⚠️ To avoid losing access to your server, make sure a working SSH key can connect before making these changes.

1. Generate a key on your machine if needed: ssh-keygen -t ed25519 -C "your_email@example.com"
2. Add the key to the server by adding the generated public key to the server’s ~/.ssh/authorized_keys file
3. Test the connection without entering a password.
4. Disable password auth in the SSH config
   • Edit the config: sudo vim /etc/ssh/sshd_config
   • Make sure password authentication is disabled with this line: PasswordAuthentication no
   • Reload the SSH config: sudo systemctl reload sshd
   • Test a new connection.

---

6. Restrict SSH access to a specific IP

In an incident context, it can be relevant to immediately restrict SSH access to a single IP address (yours) to avoid any new connection attempts. Thank you, Hugo Perez for suggesting this

⚠️ Warning: this means SSH access will be possible only from that IP.

1. Identify your public IP: curl ifconfig.me
2. Add a firewall rule - example with ufw:
   • Allow only your IP: sudo ufw allow from YOUR_IP to any port 22 proto tcp
   • Deny the rest: sudo ufw deny 22/tcp
   • Check: sudo ufw status
3. Add a firewall rule - example with iptables:
   • Allow your IP: sudo iptables -A INPUT -p tcp -s YOUR_IP --dport 22 -j ACCEPT
   • Deny the others: sudo iptables -A INPUT -p tcp --dport 22 -j DROP

⚠️ Check the rule BEFORE closing the current SSH session.

To avoid: immediately rebooting the server

If an intrusion is suspected, it is not recommended to reboot the machine immediately.

A reboot can make it harder to understand the entry vector

• removal of running processes
• deletion of some log files

Conclusion

These commands helped me validate where some connections to my server were coming from (CI, etc.). If you have suggestions for commands I may have missed, feel free to contact me by email or on social media.