I set up an SSH honeypot on my server: it pretends to be a defenceless Linux box, accepts almost any password and records everything done inside. There is no real system behind it. In the first five days it received 24,218 sessions from 683 addresses.
I wanted to see attacks on my own server rather than in reports and textbooks: who shows up, what they type, and how one attack differs from another. Other companies' statistics answer "how many"; a honeypot shows "how".
Found quickly, and the obvious gets tried first
A new session typically arrives about five seconds after the last one. The server was never advertised: it is found by scanners that constantly sweep the whole internet.
The most common passwords are predictable: 123456, 123, 1234, 12345678. Besides root, the usernames include ubuntu, admin, deploy, postgres and also claude: bots are already looking for accounts of developers who use AI tools. The conclusion is simple: password login on a public server does not last long.
One bot made almost 90% of the noise
The most interesting part was the distribution. 21,217 sessions, or 88%, came from a single family using 18 addresses. It logs in and runs one command:
uname -s -v -n -r -mThen it leaves. This does not look like a breach so much as an inventory: the bot checks whether the password worked and what system is inside. I cannot prove it, but the behaviour fits collecting a list of accessible servers to return to later or hand to someone else.
That gave the first practical lesson: counting sessions is useless. One noisy bot drowns out everything else, so I rebuilt the experiments to count addresses instead of sessions.
The most widespread family leaves a key
The family with the most addresses, 291, does something different: it removes the protection from the .ssh folder, deletes it, recreates it and writes its own key. The whole thing takes seconds:
cd ~ && rm -rf .ssh && mkdir .ssh && echo <key> >> .ssh/authorized_keysDeleting the old folder matters: on a real server it would lock out both the owner and other bots. And changing the password afterwards does not help, because the key stays. So when you suspect a breach, check not only passwords but also the authorized_keys file, cron jobs and the user list.
What bots left in the honeypot
The honeypot may not make outbound connections, so it cannot download anything. But bots upload files themselves: 22 files have piled up so far, 17 of them Linux programs for several architectures, including x86-64, ARM and AArch64. Several carry signs of XMRig, a cryptocurrency miner. The files are only examined as data and never run. The goal of most attacks is boring: someone else's CPU.
How half my defences stayed silent for two days
The most useful part turned out not to be about bots at all. Next to the honeypot run a tarpit and database decoys, and for two days their counters sat at zero. The service was running, the firewall rule was in place, and its counter was even growing. A local check passed.
tcpdump helped: requests were arriving, but no replies went out. In the end a second firewall turned up. Permission in one does not override a block in the other: a packet has to pass both. The first firewall's counter said all was well, and that was only half true.
The conclusion: a check from inside does not prove a service is reachable from outside. A firewall counter does not prove it either: it only speaks for its own part of the path. The most reliable answer came from a simple experiment: a real connection from outside while watching the packets.
What's next
The next question is whether bots pay attention to what they are dealing with. Every day the honeypot changes its disguise: the server name and the system version. In a few weeks it will be clear whether bots react or do not care. If they do not care, that is a result too, and it will get a note of its own.