How We Stopped Hiring Sysadmins: Claude Configures Our Servers Now

Disclosure. This article contains an affiliate link to Contabo. If you order a server through it, we earn a small commission at no extra cost to you. We write about Contabo not because of the partnership but because our own fleet of servers runs there. The story below is true.

The short version

For years we overpaid for peace of mind. We picked shared hosting and VPS plans specifically where the technical support was good, and that turned into a serious monthly bill. Even at that price the administration problems never went away. Something would break, something needed tuning, and anything genuinely difficult came back as “that is outside our scope.”

The turning point was a break-in on one of our servers. Nobody could help us: the admins stalled, poked at it, and got nowhere. Out of sheer desperation I decided to work it out myself and opened Claude (Claude Code) right in the terminal. Everything changed from that moment. Since I started configuring servers with Claude, the administration problems simply stopped. The surprising part was how it worked: I described in plain words what I wanted, and Claude handled the technical side, warned me about the details and suggested what else to do. We no longer need a separate sysadmin.

This article is the story of how we got there.

How it used to be: paying for support and still stuck

The logic seemed sensible. If you are not a sysadmin, buy hosting where someone does it for you. So we deliberately chose the pricier plans: shared hosting with live support, managed VPS where they promised help with anything. You pay a noticeable premium every month, multiplied by the number of projects. Together it adds up to a real line in the budget.

The trouble is that it did not save us. Support was great at restarting a service or answering a small question. The moment anything non-standard came up, though, it stopped: a migration, an nginx config for a specific case, finding out why a site returns 500, setting up a firewall. Then it was “that is application administration, we do not cover it.” You pay for support, and the actual administration is still on you. So either you also pay a separate admin, or you live with half-working setups.

That held until our luck ran out.

The day we got hacked

Later, reconstructing the timeline from the logs, we saw the whole picture:

• 14 July, 17:27. Someone logged in as root over SSH from an unknown IP. One failed attempt, then a successful login. The password was simply brute-forced.
• 17:34–18:08. Within half an hour the server had the full kit installed: a crypto miner, a rootkit to hide processes, a password stealer and self-healing mechanisms.

The worst part surfaced during the analysis. A separate SSH backdoor key had been added on 12 July, two days before the obvious attack, and not only for root but for almost every account with a real shell. The attacker had several independent ways back in.

Here is what was living on the server, all of which we later removed:

• A crypto miner disguised as the system library libudev.so.6 and launched from cron.hourly.
• The hide rootkit, so the miner would not show up in the process list.
• A PAM hook acting as a password stealer. It logged every login attempt (username, password, IP) into a hidden file.
• A resurrection script in cron.daily. An hour after the miner was deleted it reinstalled the malware from hidden copies and poisoned .bashrc.
• Six hidden backup copies of the malware scattered across /boot, /srv, /mnt, /opt and /usr/lib under random names.
• The .ssh directories with backdoor keys were protected with immutable flags (chattr +i) so they could not simply be deleted.

Anyone who has seen an infected server for the first time knows the feeling. You do not understand why things keep coming back, how much more is hidden, or whether root is still yours at all.

The admins who did not help

The first thing you do is look for someone to fix it. So did we, and this is where it got demoralising.

The admins we approached stalled. Someone took the job, did a few things, even removed part of the malware. The logs later showed files being deleted and the server rebooted several times. But it led nowhere: the miner came back, the foreign keys stayed, and the unexplained persistence was still there. Nobody could explain what was actually happening or whether the server was clean.

You pay, you wait, and nothing moves. At some point it was obvious that another day like this would cost me time, money and the server itself. That is when, out of desperation, I decided to try it myself.

How we cleaned it up with Claude

The key decision was simple: do not work blind. Instead of googling a command, pasting it and hoping, Claude and I went step by step, with an explanation for every action.

The important part: I spoke plain English, Claude did the work

This is worth dwelling on, because it impressed me most. I am not a sysadmin and I did not write a single command from memory. I just described in ordinary words what I wanted: “it looks like we were hacked, find out what they installed and how to remove it”, “make sure root can no longer log in with a password”, “close everything unnecessary, leave only the sites and mail”.

Claude took the technical side:

• It turned my request into concrete commands and explained what each one does before I ran it.
• It warned me about details and risks I would never have accounted for: allow the SSH port first or you will lock yourself out, this zero-byte file keeps coming back so dig deeper instead of deleting it, ipset will not survive a reboot so it needs its own service.
• It suggested things I had not asked about: ban repeat offenders with the recidive jail, enable automatic updates, take a snapshot as insurance before a risky step.

The division of labour was clear. I brought the decisions and the common sense (“yes, go ahead”, “no, back it up first”), Claude brought the technical side and the attention to detail. I did not have to become an engineer. I had to state the problem clearly and check the conclusions.

That is the main impression the whole story left: it was both simple and striking. Things that used to make us give up were handled in a calm conversation in the terminal.

1. Understand the scale first

We ran chkrootkit and rkhunter. They immediately flagged a possible kernel-level rootkit and hidden .ssh directories. Claude explained what each warning meant and which ones were a real threat rather than a false positive. That matters, because half the output of such tools is noise. Without understanding it you either panic for nothing or miss the real thing.

2. Strip the malware’s protection and clear the IOCs

Then it was a loop: find a component, understand how it holds on to the system, remove the chattr flags, delete it. The miner, the loader, the hide rootkit, the PAM stealer, the resurrection script, all six hidden backups. The infected .bash_profile, .profile and .bashrc were cleaned, with the originals kept as evidence. The backdoor keys were a story of their own. They had to be pulled out of every account without touching the team’s legitimate keys. When every step is in front of you, you can see whose key you are about to delete.

3. The moment we decided to reinstall

One file kept coming back. Zero bytes, SUID bit set, chattr +i, and it reappeared even after we had cleared everything: malware, cron, systemd, the PAM hook, all the backdoor keys. We checked cron, systemd timers, incron, at, kernel modules, and sampled running processes once per second. We never found the source.

The file itself is harmless, since zero bytes execute nothing. But unexplained persistence is an alarm: if you cannot explain why something comes back, you cannot promise the server is clean. So we made the honest call and reinstalled from scratch. Contabo lets you do that from the panel in a couple of clicks.

The lesson: sometimes the right answer is not to keep treating the patient but to wipe it and rebuild against a clean checklist.

The hardening checklist that is now our standard

After the reinstall we applied a baseline set of protections. This list now goes on every new VPS:

1. SSH by key only. PermitRootLogin prohibit-password, PasswordAuthentication no. The root password brute force, the exact vector used against us, stops working.
2. UFW. Allow 22/80/443 first so you do not lock yourself out, then default deny incoming and enable.
3. fail2ban with the sshd and recidive jails, banning repeat offenders for a week.
4. The blocklist.de list via ipset. Around 18,000 known malicious IPs are dropped at the door, refreshed daily by a systemd timer.
5. The Contabo cloud firewall. A separate layer at the provider level, before traffic even reaches the server. Default-deny, with only what each role needs opened up.
6. Automatic updates (unattended-upgrades), so critical patches install themselves.

Small traps we walked into, so you do not have to:

• In ufw’s before.rules, an -A rule must come after the chain declaration :chain - [0:0]. Otherwise iptables-restore fails quietly and ufw reload says nothing.
• ipset lives in memory and does not survive a reboot. It needs a restore service that loads the set before ufw starts.
• On Ubuntu 24.04 fail2ban writes to the journal, so the recidive jail needs its log file specified explicitly.

None of this is rocket science. But collected into one repeatable checklist, a server stops being a lottery.

What changed: no sysadmins needed

The biggest change is not technical but mental: the server side stopped being scary. We are no longer site owners who are afraid of the terminal. We check, update and close ports ourselves, with Claude as a co-pilot that explains each step and catches mistakes before they run.

In practice:

• The same hardening checklist is now rolled out across the whole fleet, so every new server comes up protected from minute one.
• Through the Contabo API we keep an inventory of servers, manage cloud firewalls and take snapshots with scripts instead of clicks.
• And the money part: we stopped paying for expensive managed hosting and separate support that fell short anyway. Tasks that used to need either a costly specialist or a managed plan now take an evening, with a clear understanding of what you are doing and why.

Does that mean Claude “replaced” a system administrator? At our scale, essentially yes: we no longer need dedicated sysadmins. The barrier dropped so far that administration is no longer its own budget line. Claude still needs checking, and we do check, especially before deleting anything in production. But it is a partnership rather than helplessness or an hourly invoice.

Why Contabo

When you no longer need an admin or paid support, your choice of hosting changes too. We used to pay a premium for managed plans precisely because of “they will help.” Now Claude helps, so it makes sense to take a cheap but powerful unmanaged VPS instead of an expensive plan with support you do not use. Contabo fits that perfectly:

• Price to power. For the money that buys a tiny instance in the big clouds, you get a VPS with a decent CPU, several gigabytes of RAM and a reasonable disk.
• European data centres, which matters for latency and GDPR.
• A cloud firewall at the provider level, an extra layer of protection, free in the panel.
• A full REST API for inventory, snapshots, firewalls, reinstalls, private networks and object storage. All of it scriptable.
• Reinstall and rescue in two clicks, which is what saved us during the clean rebuild.

There are downsides. Support is not instant and the panel is bare-bones. But when you do not need support every day, that stops being a downside. You are not paying for something you never use.

👉 See Contabo VPS plans: contabo.com/vps

Conclusion

For years we paid for peace of mind in the form of managed hosting and support, and we still had administration problems. What solved them was not a more expensive subscription but the combination of a cheap flexible VPS and an AI assistant in the terminal. Not because we became sysadmins, but because we stopped working blind, and stopped overpaying for the privilege.

If you are also keeping sites on an expensive managed plan for the sake of calm, try the other route: an affordable VPS and a basic checklist (SSH by key, fail2ban, a firewall). That alone removes the attack vector that got us, and shows you how much you were really paying extra.

---

FAQ

Can you really manage without a system administrator? For a fleet of ordinary sites (nginx/PHP/MySQL, WordPress, Joomla and so on), yes. The routine work of setup, updates, firewalls, error triage and backups happens in the terminal with an AI assistant that explains every step. For rare complex cases you can always bring in a specialist once, which is no longer a monthly cost.

How much do you save by dropping managed hosting? It depends on the fleet, but the gap between a managed plan with support and an unmanaged VPS of the same power is often several times over. Multiply the premium by your number of projects and months to see the budget that was going toward “calm”.

Is it safe to give AI access to a production server? You are not giving access. You work in the terminal yourself while the AI proposes commands and explains them. You see and confirm every action. The rule is simple: before any deletion or change in production, read what is about to run.

What should I do right now if I suspect a server has been compromised? Do not reboot blindly, because you will lose evidence held in memory. Take a snapshot for forensics, run chkrootkit and rkhunter, check authorized_keys in every account, and look for recent entries in cron and systemd. If you find persistence you cannot explain, plan a clean reinstall followed by hardening.

What is the minimum protection every VPS should have? SSH by key only, password login disabled, fail2ban, a default-deny firewall and automatic updates. Five items, half an hour of work, and 99% of automated attacks no longer reach you.

---

*This article is based on a real incident in our own infrastructure (July 2026). Technical details, IP addresses and credentials have been generalised deliberately for security reasons.*

Photo credits: Gabriel Heinzer, Kevin Horvat and Domaintechnik on Unsplash, Paras Katwal on Pexels. Used under the free Unsplash and Pexels licences.