Your Server's First Hour Is the Whole Attack Surface

A server with password authentication enabled is not "unhardened yet" — it is a live, addressable target from the second its IP is routable, and the interval between creation and hardening is the only security control you have not applied.

That interval is the subject of this article. It is short, it is almost never measured, and it is where a large share of small-infrastructure compromises actually happen. Most hardening guides start at the firewall rules and never mention the window at all, because the window is a scheduling problem rather than a configuration problem — and scheduling problems do not fit neatly into a checklist.

What follows is what the honeypot data says about that window, one diagnostic signal you can run in ten seconds, a table of five things that look like an attack but are not, and the smallest set of changes that closes the gap.

The window is a scheduling problem, not a configuration problem

Every guide to securing a Linux server follows the same shape: disable password authentication, disable root login, install a firewall, enable automatic updates, deploy fail2ban. The list is correct. The order is also more or less correct. What none of them state is that the list is a sequence, and a sequence has a duration.

Between the moment the provider hands you a routable IPv4 address and the moment you have applied the first item on that list, your machine is running a default sshd configuration with password authentication enabled. On a stock Ubuntu image, that is PasswordAuthentication yes and, depending on the image, root login by password. Those defaults exist so that you can get in at all — the provider has no other way to hand you credentials. They are not a bug. They are a documented convenience with a documented cost, and the cost is exposure.

The reason this matters more than it sounds is that the exposure is not proportional to the length of the window in a way that lets you relax. Attack traffic is not scheduled. It is continuous. A machine that is online for eleven minutes is not "eleven minutes safe" — it is online for eleven minutes during which the entire background noise of the internet is arriving at port 22.

What the honeypot data actually shows

The cleanest recent measurement of this background noise comes from a 2026 study that deployed eleven SSH honeypots for fifteen days and collected 177,622 authenticated sessions. The authors — Valeros, Sladić and Garcia, in "Ghost Without Shell" (arXiv:2606.28006, submitted 26 June 2026) — were not studying hardening at all. They were testing whether honeypots still work, because the entire deception-research literature assumes attackers log in, open a shell, and type commands.

The assumption did not hold. Of the 177,622 authenticated sessions, 99.23% were non-interactive. Sessions that involved an actual interactive shell were 0.10%. The pattern reproduced in an independent third-party dataset covering the same window, and the paper cites an earlier large-scale measurement of 546 million sessions across 221 honeypots over three years with the same shape.

The immediate consequence for deception research is that a honeypot measuring success by session length or command count is measuring a rounding error. The consequence for anyone running a server is more direct: authentication success is the event worth watching, and it happens without any of the behaviour you would normally associate with an attacker. A login that lasts 40 milliseconds and produces no commands is a complete, successful attack. It is also perfectly legal traffic from sshd's point of view.

Those non-interactive logins are automated clients that authenticate, run one command or none, and disconnect. In the honeypot datasets they overwhelmingly attempt to establish persistence — dropping an authorised key, appending a cron entry, or pulling a payload — and they leave before any human-scale monitoring would notice.

One signal you can check in ten seconds

Most monitoring starts at the wrong end. People watch failed authentication attempts, because those are numerous and dramatic, and they trend upward forever. Failed attempts are noise. On a public IPv4 address they never stop, and a machine that has been online for a week will have tens of thousands of them regardless of anything you do.

The signal that matters is successful authentication from an address you do not recognise. On a systemd-based distribution that is two commands:

• last -ai | head -20 — recent logins with resolved source addresses. Look for anything that is not you.
• journalctl -u ssh -u sshd --since "7 days ago" | grep -i accepted — every accepted authentication in the window, with the source IP and the authentication method.

If both return only your own addresses, your window did not get used. If either returns an address you cannot account for, the machine was accessed and you should treat everything on it as untrusted — including any credential stored on it, any key present in an authorized_keys file, and any token in an environment variable.

The reason to run this rather than a dashboard is that a dashboard shows you a rate, and a rate hides the single event that matters. One unrecognised accepted login in a month of normal-looking traffic is the whole finding.

Five things that look like an attack and are not

The signal above is only useful if you do not panic at the wrong input. These five produce alarming-looking output on a completely healthy machine, and misreading them leads to wasted effort at best and a rebuilt server at worst.

The asymmetry worth internalising: failed attempts are a property of having a public address, and successful attempts are a property of your configuration. You cannot reduce the first, and you must eliminate the second.

Why credential reuse turns an unrelated breach into your problem

The reason password authentication is the wrong control for anything reachable from the internet is not that passwords are guessable in the abstract. It is that the credential space attackers draw from was populated somewhere else entirely.

Specops Software's 2026 Breached Password Report, published 10 March 2026, analyses more than six billion malware-stolen credentials collected during 2025. Six billion is far larger than any wordlist. It means the practical attack is not guessing — it is replaying a pair that already worked on some unrelated service, on the assumption that the same pair was reused on a server nobody thought of as customer-facing.

The classical counter-argument is that a long random password is unguessable. That is true and irrelevant, because the password is not being guessed. It was harvested from a forum or a shop or a game account in 2023, and it is now a line in a file that gets replayed against every SSH endpoint the internet can reach. The Microsoft Digital Defense Report 2026, published 2 October 2026 and covering threats observed between July 2025 and June 2026, found that within incidents involving a valid account, 52.2% proceeded to further credential theft. One working login on one host is not a contained event; it is a foothold used to collect the keys to everything else.

That report also records that phishing-caused intrusions rose from 7% of observed incidents in 2025 to 23% in 2026. The mechanism is the same in both cases: the attacker does not break the lock, they use a key that was already copied. Which is why the control that actually works is not a stronger password but the removal of the password as an authentication factor on anything addressable from the internet.

The fastest fix, and why it takes about ninety seconds

All of the above collapses to three changes, and the first one closes the vast majority of the gap on its own.

1. Disable password authentication. Set PasswordAuthentication no in /etc/ssh/sshd_config.d/99-hardening.conf, having first installed your public key in ~/.ssh/authorized_keys. Then restart the service. Cryptographic authentication removes the replayable-credential path entirely — not by making the password harder to guess, but by making it not an accepted factor.
2. Disable root login. Set PermitRootLogin prohibit-password, or no if you have a working unprivileged sudo user. This removes the account with the largest blast radius and the most attractive name in every dictionary.
3. Restrict what is reachable. Port 22 open to the world is only necessary if you genuinely connect from arbitrary networks. A firewall rule scoped to your office and VPN ranges removes the attack surface rather than hardening it.

The reason this takes ninety seconds rather than an afternoon is that steps one and two are two lines in a drop-in file and one service restart. Step three depends on whether you have a stable egress address. In practice the ordering that matters is: get the key in place, disable password auth, and only then start thinking about anything else — because until password auth is off, everything else is mitigation rather than prevention.

There is a fourth item worth adding only after the first three: an intrusion-prevention daemon. Tools such as fail2ban and sshguard parse authentication logs and add firewall rules against repeat offenders. They are useful for reducing log volume and for slowing down distributed attempts. They are not a substitute for step one, because a daemon that blocks after N failures has already permitted N attempts, and because a distributed attempt against a single valid credential pair does not need N tries. The relevant passage on that failure mode is in the analysis of verification-endpoint abuse, where the cheapest attack in a system is rarely the one with the most attempts.

What your logs will not tell you

One honest limitation belongs here, because it changes what you should do after reading the commands above.

If your window was used, the logs give you the fact of the login and the source address. They generally do not give you a clean account of what happened next, for three reasons. Non-interactive sessions — the 99.23% case — can complete in a single connection with no shell history written at all. An attacker who gained access with a valid credential may legitimately be logged as an accepted login indistinguishable from your own. And if a payload was dropped, the artifact may be the only trace, with the authentication record showing nothing unusual about the method.

Which means the runbook after a confirmed unrecognised login is not "check the logs more carefully". It is: rotate every credential that machine can reach, including cloud API keys, database passwords and any token in the environment; compare ~/.ssh/authorized_keys against what you expect; check crontab -l and /etc/cron.d; and rebuild rather than clean, because you cannot enumerate what you cannot observe. The same reasoning applies to recovery copies — why a snapshot taken from an already-compromised host inherits the compromise rather than escaping it is worth understanding before you reach for one as a reset button.

Hardening is a rehearsal, and rehearsals need disposable machines

The awkward part of this advice is that the first three steps are best learned on a machine you can afford to lose. The natural way to internalise "disable password auth before anything else" is to do it once, break your own access, and recover through the provider's console — and you do not want that lesson to happen on production.

There is also a scheduling reality. Most of the window-closing work is front-loaded: the changes are minutes long, but the confidence that a firewall rule, a key-only configuration and a working console fallback all actually work together takes longer than minutes. Committing to an annual plan to run a two-hour experiment produces the worst ratio of cost to learning available.

SurferCloud offers a short-term UHost trial built for exactly this shape of work — a 3-day or 7-day instance at starter pricing, USD 1.9 and USD 3.9 respectively for the 2 vCPU / 2 GB configuration, with 2C4G at USD 4.9 / USD 6.9 and 4C8G at USD 5.9 / USD 10.9. The trial runs on the same console, API and image set as a full instance, which is the property that matters here: a hardening rehearsal on a trial machine produces configuration you can carry to production unchanged. Each user is limited to one trial instance, and configuration changes and region changes are not supported during the trial, so decide the sizing before you start and treat the machine as a fixed target.

Where the disposable-machine argument gets stronger is in the things you cannot verify by reading. Whether a console fallback works when you have locked yourself out is a fact, not an opinion. Whether your provider firewall rule and your local rules interact the way you think is a fact. Whether the image you chose ships with password authentication on by default — and which user it creates — is a fact that varies by distribution. A short, cheap, throwaway instance converts all three from assumptions into tested configuration.

This also connects to the wider pattern: the security boundary of a workload is the set of credentials it can reach, not the list of ports it listens on. That framing is laid out in full for automated workloads, and it applies with equal force to the human-operated case — every credential a host can read is inside its blast radius the moment someone gets a shell on it.

Frequently asked questions

How long is the dangerous window? From the moment the address is routable until password authentication is disabled. Scanning is continuous, not scheduled, so the window is exposure time rather than a probability of being found. In practice this means the fix belongs in your provisioning script, not in a follow-up ticket.

Is changing the SSH port worth doing? It reduces log volume, because commodity scanners predominantly target port 22. It does not reduce exposure, because scanners that matter scan all ports. Treat it as log hygiene, not as a security control.

Do I still need fail2ban if password auth is off? It is optional. With password authentication disabled there is no replayable credential to guess, so the daemon's remaining value is reducing log noise and slowing distributed attempts. Keep it if you find the logs useful; do not let it stand in for the primary control.

How do I know whether my window was used? Run journalctl -u ssh -u sshd --since "30 days ago" | grep -i accepted and account for every source address. If one is unfamiliar, rotate the credentials that host can reach and rebuild rather than investigate in place.

Is a trial instance suitable for this? It is one of the better uses for one, because the value is in testing fallbacks you hope never to need. The limits to plan around are the single-instance cap and the fact that configuration and region changes are not supported mid-trial.

The short version

Password authentication on an internet-facing server is a replayable credential, and the credential space was populated by breaches that have nothing to do with you. Failed login attempts will never stop and are not a signal. Accepted logins from unrecognised addresses are the signal, and checking for them takes two commands. Disabling password authentication takes one line and removes the entire class of attack. Everything else — firewalls, intrusion-prevention daemons, port changes — is a second layer on top of a first layer that has to exist.

If you want somewhere to practise that sequence without risking anything that matters, the UHost 3-day and 7-day trial starts at USD 1.9 and runs on the same console and images as production, which is what makes the configuration transferable rather than throwaway.