How to Secure a Linux Production Server

A Linux production server is not “secure” because a panel showed a green tick. It is secure when few people can log in, unused services cannot be reached, software is patched on a schedule, secrets are not in git, and you can restore the machine if the disk dies on a Tuesday. This is a baseline for operators who run a VPS or dedicated host. It is not a penetration-test playbook, and it does not describe how to attack a system.

If you are still deciding whether you need a server you fully administer, start with shared hosting versus VPS versus dedicated infrastructure. Shared hosting hides most of this work. A VPS puts it on you — or on Palmate’s cloud hosting and DevOps practice.

What “baseline” actually means

Baseline security is the set of controls you apply before the application is interesting. Attackers do not need a clever story about your product if they can guess a password on port 22, find an unpatched package with a public advisory, or read a .env file that was copied into a public repository.

A useful baseline answers five questions:

1. Who can reach the administrative interface, and how?
2. What is listening on the public network, and why?
3. How do patches land without relying on someone remembering?
4. Where do secrets live, and who can read them?
5. If the box is gone, how long until the business has its data back?

Web application hardening, container isolation, and monitoring sit on top of those five. If you skip them, later work is theatre.

SSH: keys, users, and a narrow door

SSH is the front door. Create a named user for each person who needs access. Do not share a single ubuntu or root password in chat. Grant sudo only to people who must install packages or restart services. Disable direct root login over SSH once named users work.

Prefer public-key authentication and turn off password authentication once keys are proven. Keys should live on devices people control, with a passphrase on the private key. When someone leaves, remove their key from authorized_keys the same day.

Keep SSH updated with the rest of the OS. Restrict which users may log in if the distribution supports an allow-list. If the team only connects from office or VPN addresses, limit SSH to those networks.

Two habits matter more than clever SSH configuration:

• Never paste private keys into tickets, emails, or chat. If a key may have leaked, replace it.
• Keep a second, tested way in (provider console, or a documented break-glass user) so a botched firewall rule does not lock you out.

This is access hygiene, not a substitute for application authentication, and not a guide to probing other people’s servers.

Firewall: default deny, then exceptions

A firewall should start from “nothing inbound except what we named.” On a typical web application host that list is short: SSH from trusted sources, HTTP and HTTPS for the site, and nothing else unless you have a documented reason (mail, a VPN, a database that must not be public).

Databases, Redis, admin panels, and Docker-published ports are frequent mistakes. If PostgreSQL is bound to 0.0.0.0 on the default port, the firewall is the only thing between the internet and your customer data. Bind internal services to localhost or a private network, and still keep the firewall closed.

Write down the allowed ports in the same place you keep DNS notes. The next engineer should not have to guess why 8080 is open.

When you put a reverse proxy in front of containers, the host firewall and the proxy both matter. Containerisation does not make a published port private. See the sample containerised VPS delivery study for how edge, runtime, and deploy fit together without turning the VM into a pet.

Updates: a schedule, not a mood

Unpatched kernels and libraries are how ordinary hosts get into incident reports. Enable automatic security updates for the distribution when that matches your risk (many Debian/Ubuntu servers use unattended upgrades for the security pocket). Reboot when a kernel update requires it — preferably in a window you chose, with a health check afterwards.

Pin a calendar reminder if automatic reboots are too aggressive for your application. The failure mode to avoid is “we never reboot because something might break,” which eventually means you are running a kernel with a known, widely discussed defect.

Application dependencies are a separate stream: container images, language runtimes, and libraries in your lockfile. Rebuild images on a cadence. Do not run a three-year-old base image because “it still works.”

Secrets: not in git, not world-readable

Secrets are API keys, database passwords, JWT signing material, SMTP credentials, and cloud access keys. They do not belong in the repository, in world-readable files, or in screenshots of “working config.”

Practical rules that survive contact with a small team:

• Store production secrets in files with restrictive permissions, or in a secrets manager, and inject them as environment variables at runtime.
• Keep .env and compose override files out of git. Provide .env.example with dummy values.
• Rotate a secret when a contractor’s laptop is gone, when a key appeared in a log, or when a former staff member still had shell access.
• Prefer short-lived credentials for CI. A deploy key that can only pull images is better than a god-mode cloud user in GitHub Actions.

If you must debug a production payload, sanitise it. Browser tools such as the JSON formatter still do not make it wise to paste a live session token onto a shared machine.

Backups: a restore you have actually done

A backup you have never restored is a rumour. Define three things in writing: what is backed up (database dumps, uploaded files, secrets store), where copies live (off the same VPS — object storage in another region or another provider), and how often you test a restore.

Encrypt backups in transit and at rest if they contain customer data. Restrict who can download them. A world-readable backup bucket is a data-breach waiting for a search engine.

Run a restore into staging, not only a “job succeeded” tick. Time it. If restore takes six hours and your business can tolerate one hour, you do not have a backup strategy — you have a file collection.

Pair this with launch hygiene. The website launch checklist includes backup and deployment items that are easy to skip when everyone is staring at DNS.

Accounts, TLS, and logs

Remove unused packages and default accounts. Turn off services you did not install on purpose. Use TLS with automatic renewal; expired certificates are both an availability and a trust problem.

Centralise logs enough to answer “who logged in last night?” Rotate or ship logs before they fill the disk. Time-sync the machine so logs and certificates make sense. Monitor disk, certificate expiry, and process health. Failed SSH attempts are constant on the public internet; they are a signal, not an emergency by themselves.

What this baseline does not replace

Application bugs and a full audit against a named standard are outside this article. Payments or health data need controls this list does not pretend to cover. Changing the SSH port is optional obscurity; keys, patching, firewalls, secrets, and tested backups are the programme.

A short operating checklist

Control	Done when
SSH	Named users, keys only, root login off, leavers removed
Firewall	Default deny inbound; only documented ports
Updates	Security patches applied; reboot plan for kernels
Secrets	Not in git; restricted files or a manager; rotation path
Backups	Off-host copies; restore drilled in staging
TLS	Valid certificates; renewal automated
Access	Provider console documented; sudo limited

If you want help turning this into a documented environment rather than a one-off SSH session, cloud and DevOps is the Palmate service that covers Linux baselines, Docker, proxies, and backup drills. For a wider hosting choice, read the VPS versus cloud hosting guide after you know you can operate the box you buy.