What 1,241 login attempts a day taught us about remote access security

Ask most small business owners whether anyone would actually bother attacking their systems and you get the same answer. We're too small. Nobody's heard of us. There's nothing worth taking.

We build audit software for a living, so instead of guessing we pointed it at a production server we manage and counted. In the twenty-four hours before we looked, that server, the one running this website and three of our applications, had fielded 1,241 attempts to guess a password. Machines working through a list, not a person at a keyboard, one password after another, all night.

We've written that incident up in full elsewhere on this site, with the numbers and the fix: see what actually happened. This piece is the wider version. What SSH and remote access actually look like from the attacker's side, why the mistake behind that finding is so common that almost nobody notices it, and what a business with no security team can realistically do differently.

Every open door gets tried, not just the interesting ones

SSH is the standard way an administrator logs into a Linux server remotely. Type the right address, prove who you are, and you're in a command line with full control of the machine. It's an old protocol, dating back to 1995, still entirely fine when it's configured properly, and it sits behind port 22 on more or less every internet-facing Linux box on earth.

That last part is the whole problem. Port 22 being open isn't a mistake. It's normal, expected, usually necessary. But it also means every server running SSH is sitting on a list somewhere, and automated scanning tools work through that list continuously, without caring who you are or what you sell. Being small isn't camouflage. It never was. Your address exists, and a program somewhere is working through every address it can find, yours included, on a schedule that has nothing to do with your size.

What actually makes a login attempt dangerous

An attempt on its own is nothing. Password authentication has been standard for decades, and most systems survive millions of failed logins without incident, because most systems require something a brute-force script can't produce quickly: a strong, unique password, and ideally a cryptographic key instead of a password at all.

A key is a file, typically a couple of thousand characters of effectively random data. There's no dictionary to run against it and no pattern to guess. Generate one, put the public half on the server, keep the private half on your own machine, and a password-guessing script has nothing left to try. Most Linux servers support this out of the box. Plenty never get switched over, because password authentication worked fine on day one and nobody ever circled back.

The second setting that matters is whether the root account, the one with unrestricted control of the whole machine, can log in directly. On the server we checked it could. Combine that with password authentication and the only thing standing between a stranger and complete control was guessing one string correctly, which is exactly what 1,241 machines a day were trying to do.

The mistake that had nothing to do with SSH

Here's the part worth reading even if you never touch a server yourself, because it isn't really about SSH at all.

We edited the configuration file to switch both settings off. The syntax check passed. Everything looked finished. Password logins were still enabled.

Modern Linux systems read a main configuration file, then a folder of smaller override files layered on top, and the overrides win. One of those override files, written automatically when the server was first provisioned, quietly said "allow passwords" and outranked the change we'd just made. We only caught it because we asked the running service what it had actually decided, rather than trusting the file we'd just edited and assuming the job was done.

That's the part that travels beyond this one server. A firewall rule you added last month, a Group Policy setting pushed down from a domain controller, a cloud security group someone else manages, a router configuration inherited from an ISP install: all of them can have a layer sitting underneath your edit, quietly winning. Checking the file you changed tells you what you intended. Checking the live, effective configuration tells you what's actually true. Those are two different questions, and only one of them protects you.

RDP is the more famous version of the same problem

SSH gets the attention here because it's what we found on the server we checked, but Windows Remote Desktop Protocol is the bigger story across the industry as a whole, if the reporting is anything to go by. It's one of the most widely reported ways ransomware groups get their first foothold on a network: an exposed RDP port, a weak or reused password, no second factor required. Microsoft's own BlueKeep vulnerability, disclosed in 2019, was serious enough that the NSA and GCHQ both issued public advisories urging organisations to patch it, a reminder that RDP itself can carry flaws on top of the credential problem.

The fix is the same shape as SSH, even though the mechanics differ. Don't leave it open to the entire internet if you can avoid it. Require more than a password. Don't let an administrator account log in directly from anywhere in the world. If your business allows remote desktop access into a server or a workstation and nobody's checked how it's configured in the last year, put that at the top of the list, not the bottom.

A practical checklist for small business remote access

None of this needs an enterprise security team. Most of it is a setting, not a project.

• Key-based authentication only, on anything Linux. Turn password logins off entirely once a working key is confirmed, not before.
• No direct login for admin or root accounts. Log in as a named user and switch to admin access only when the task needs it, so there's an identity attached to every session.
• Multi-factor authentication wherever it's offered, including RDP and any cloud admin console, not just email.
• An automated lockout tool — fail2ban on Linux, account lockout policy on Windows — so repeated failures get banned rather than left to keep trying.
• Restrict by source where you realistically can, whether that's a VPN, a bastion host, or an IP allow-list for a small, fixed team.
• Patch the software doing the listening, not just the operating system underneath it.
• Check the effective configuration, not the file. One command tells you what a service has actually decided; reading the file you edited only tells you what you intended.

None of these took more than an afternoon to check on the systems we manage, once we knew to look. The habit of checking is the part that has to stick.

What we changed, and how we know it held

We've laid out the full walkthrough, with the numbers and the three checks we ran to confirm it, in the case study. The short version: root can no longer log in with a password anywhere on that server, passwords aren't accepted at all any more, and we proved the change three separate ways rather than taking the configuration file's word for it a second time. The whole change took about twenty minutes once we'd actually found the problem, and it cost nothing beyond the time.

The addresses doing the attacking don't appear anywhere in that write-up, or in this one. An IP address can be personal data under UK GDPR, and publishing a list of them would tell you nothing useful about your own risk anyway. The number that matters is 1,241, not which machine sent attempt number 812.

How we check this for clients

This is exactly the kind of finding our audit tooling is built to surface, run from outside your own network the same way we ran it against the server in this article, because that's the only vantage point that shows what the internet can actually reach. We've written up how an audit actually runs, including a sample report, if you want to see the format before booking anything.

The outside-in check itself is free. No visit, no obligation, and you get the findings whether or not you ever hire us to fix them.

Somebody is trying your address right now, whether you've looked or not. The only real question is whether anyone's checked what would happen if they got lucky.