The first hour: a smaller attack surface.

Verify and preserve access

Confirm the server identity through a trusted channel and add your SSH public key. Create a named administrative user. Keep the original session open while testing the new one and record the recovery method before changing authentication.

Patch and reduce exposure

Install supported security updates and reboot if needed. Review listening services and permit only the necessary ports in the firewall, including IPv6. Remove unused daemons and avoid opening a database publicly merely to make setup easier.

Separate users and secrets

Run applications under their own accounts. Put private configuration outside the public web directory and exclude it from version control. Use narrow database privileges and separate credentials for production and experiments.

Leave a working recovery path

Set log rotation, disk alerts and a separate backup. Reboot once to verify the application starts correctly. Record what changed so the configuration can be rebuilt on a clean image.

Check before closing the session

Open a second connection using the new account, verify administrative elevation and test the firewall from another client. Confirm the service returns after reboot. Keep the provider recovery route documented so a mistaken network rule does not require an improvised recovery.

A first-day verification list

Review open sockets, recent authentication events, update status, backup age and disk use. Check that private configuration and version-control metadata cannot be fetched over HTTP. Use the smallest set of installed tools that supports the actual workload.

ss -lntup
df -h
free -h
systemctl --failed

Make access changes in a reversible order

First confirm the console or rescue route and verify the SSH host key through a trusted provider channel. Install the public key for a named administrator, then open a second connection and test privilege elevation. Validate SSH configuration syntax before reloading the service. Apply firewall changes only after the intended SSH route is allowed. Disable an old authentication method after the replacement works from a fresh session, with any required second-factor flow included.

• Inspect effective configuration and included snippets; a setting in one file may not be the final policy.
• Check both password authentication and keyboard-interactive policy when reviewing a key-based login design.
• A non-default SSH port can reduce background noise, but it does not replace verified keys, access limits or updates.
• Use the service name and reload procedure for your distribution. Keep the original session until the new policy is proven.

# Validate before applying a changed SSH configuration.
sudo /usr/sbin/sshd -t
# Read effective settings; adapt user, host and client address to the test.
sudo /usr/sbin/sshd -T -C user=admin,host=server.example,addr=198.51.100.10

Official documentation: OpenSSH: server configuration manual

Prove the firewall from outside the host

Review the provider network firewall and the guest firewall as separate controls. Test the intended service over IPv4 and IPv6 from another authorised machine. A local connection proves only that a process is listening. Do not blindly deny every ICMP packet: normal network operation also needs appropriate control traffic. Check container-published ports against the actual rules because application exposure may not match the policy you thought a firewall front end applied.

• If SSH fails, inspect source-address restrictions, the listening interface and the provider firewall before repeatedly changing keys.
• If HTTPS fails, check DNS, the process listener and the local/proxy firewall in that order.
• Before the first production dataset, verify update status, a clean reboot, disk alerts and an independently restorable backup.
• Set a documented timezone and verify time synchronisation. Do not add arbitrary swap or logging settings without checking the workload’s memory and retention needs.

Official documentation: Ubuntu Server: firewall administration