A newly created cloud server with a public address starts receiving automated login attempts within minutes. That is the ordinary case, not an attack on you specifically. The good news is that a short, fixed list of changes removes essentially all of that risk, and all of them belong in the first session.
Add the key at creation, not afterwards
Every provider in this catalogue lets you attach an SSH public key when the instance is created, which means the machine never exists in a state where a password would work. That is meaningfully safer than creating with a password and hardening later.
If you do not already have a key pair, generate one with a modern algorithm and a passphrase, and keep the private half on your own machine only. A key you have emailed to yourself is no longer a secret.
Create a working user
Logging in as root for daily work removes the one safety net between a mistyped command and an unbootable server. The pattern is:
- Create an ordinary user.
- Copy your public key into that user’s authorised keys.
- Grant it administrative rights through sudo.
- Verify you can log in as that user in a second terminal before closing the first.
That last step is the one people skip and regret. Keep the working session open until the new path is proven.
Turn off password authentication
Once key login works, disable password authentication and direct root login in the SSH daemon configuration, then reload the service. This single change ends the entire category of brute-force attempts, because there is no longer anything to guess.
Two related decisions people over-think:
- Changing the SSH port reduces log noise. It is not a security control, and treating it as one is a mistake.
- Fail2ban or equivalent is useful for services that must accept passwords. With key-only SSH, it is largely redundant on that port.
Turn on automatic security updates
Unattended upgrades for security patches, on by default, is the highest-value ongoing habit on any server. Configure it in the first session, because nobody comes back to it later. Reboot-required situations should be reported somewhere you will see them — a kernel update that is downloaded and never applied protects nothing.
Close everything you do not serve
The firewall is a separate topic and a separate control, and both the provider-level firewall and the host firewall are worth having. Firewall rules for a new cloud server covers the minimum safe default and why management ports should never be open to the whole internet.
The checklist
- Key attached at creation, private key never leaves your machine.
- Non-root user with sudo, verified in a second session.
- Password and root SSH login disabled.
- Automatic security updates enabled.
- Firewall restricting management ports to your own addresses.
- Hostname and time synchronisation set, so logs are readable later.
- A note somewhere durable recording what this server is and who owns it.
That last item sounds administrative and prevents the most common operational failure of all: a server nobody dares turn off because nobody remembers what it does.
Where to go next
- Your first hour with a new cloud account — the account-level equivalent of this list
- Snapshots vs backups
- Monitoring a cloud server
Questions
Frequently asked
Should I use a passphrase on my SSH key?
Yes. Without one, anybody who copies the private key file has your server. An agent holds the decrypted key for the session, so you type the passphrase once rather than on every connection.
Is changing the SSH port a security measure?
It reduces automated log noise and nothing more. Key-only authentication is the control that actually matters; a non-standard port is cosmetic by comparison.
Can I still use passwords for some logins?
You can, but not on SSH exposed to the internet. If an application needs password authentication, put it behind the firewall or a VPN rather than making SSH weaker.