Job linux-baseline-ssh-keys-firewall-updates-verified · revised 11 October 2026
Harden one Linux server: key-only SSH, a firewall and automatic security updates
One Debian or Ubuntu server gets key-only SSH, a deny-by-default firewall and automatic security updates, each checked from outside. It is not a penetration test or a certification.
You might be seeing
- Password login for SSH still works from anywhere
- Nobody can list which ports are reachable from the internet
- Nobody knows when the last security update was installed or whether one is waiting for a reboot
No passwords, keys, card details or admin invites needed to start.
What usually happened
A new VPS is usually reachable over SSH with whatever the provider enabled, services listen on more ports than anyone intended, and updates are applied only when someone remembers. Changing SSH settings or the firewall in the wrong order can lock the owner out of their own server, a later setting in a drop-in file can quietly undo an earlier one, and ports published by Docker can sit outside the host firewall's rules.
Who it’s for: A founder or small team that runs a VPS themselves and cannot say who can log in, which ports are open to the internet or whether security updates are being installed.
Usually starts when: The server went live with the provider's defaults, a former contractor may still have access, or a customer or investor asked what protects the server.
The result: On one server, SSH accepts only the named public keys and refuses password logins, the firewall denies incoming traffic except the ports you list, and security updates install automatically under a reboot policy you chose. Each setting is checked on the effective configuration and from outside the server. This is a configuration baseline, not a penetration test or a compliance certification.
Check whether this job fits
Four checks that decide whether this fixed job fits. Your answers stay on this page unless you choose to email them.
Checks you can run yourself
See what is listening
Run this on the server. It lists listening sockets and does not change anything.
ss -tulnLook for: Entries on 0.0.0.0 or [::] with ports you do not recognise. Those listen on every interface and are limited only by the firewall.
Read the effective SSH settings
This prints the settings sshd would use, after every included file. It does not change them.
sudo sshd -T | grep -E '^(passwordauthentication|kbdinteractiveauthentication|permitrootlogin|pubkeyauthentication) 'Look for: passwordauthentication yes means password logins are accepted. permitrootlogin prohibit-password means root can log in only with a key.
What you get
- The changed configuration, as files and a plain-language list of what each change does
- A verification sheet: effective SSH settings, the outside port check, the update dry run and the timer status
- The steps to revert SSH, firewall and update changes, and a list of anything found that is outside this scope
Included
- One Debian or Ubuntu server with a release that still receives security updates
- SSH: key-only login for named administrator accounts, password and keyboard-interactive login off, root login by password off, verified on the effective configuration
- Firewall: default deny for incoming traffic with allow rules for the ports you list, covering IPv4 and IPv6, and a check of any port published by containers
- Automatic security updates: enabled for the security origin with a dry run, a log check and a reboot policy you choose
- A verification sheet and the steps to revert each change
Not included
- Penetration testing, vulnerability scanning, a compliance audit or any certification (for example SOC 2, ISO 27001 or PCI)
- Investigating or cleaning a server you think has been compromised
- Web server, database, TLS and application hardening
- Ongoing patching and review: that is the monthly server patch and review service
- VPNs, bastion hosts, intrusion detection and multi-server network design
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
The effective SSH configuration shows password and keyboard-interactive login off and root login by password off, and a password login attempt from outside is refused.
Evidence: The test-mode output for those settings and the refused attempt.
ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no admin@server.yourbusiness.co.ukEach named administrator logs in with their own key in a second session opened before the first was closed, and a key that is not on the list is refused.
Evidence: Session logs for each administrator and for the refused key.
From outside the server only the agreed ports accept connections on IPv4 and IPv6, and every other tested port is closed or filtered. Any port published by a container is listed with its result.
Evidence: A table of tested ports and results from a machine outside the server.
The automatic update dry run lists the security origin as allowed and completes without error, and the update timers are enabled.
Evidence: Dry-run output and the timer listing.
sudo unattended-upgrade -v --dry-runThe reboot setting you chose is shown in the configuration, and the handover states whether a restart is pending on the server today.
Evidence: The configuration lines and the pending-restart check.
Following the revert steps on the rehearsal copy restores the previous SSH and firewall settings.
Evidence: Revert transcript with the effective settings before and after.
Sign-off. You sign off after your second login works, the outside port check and the update dry run pass, and you have the revert steps. Payment follows sign-off.
If it fails. If an agreed check fails and cannot be fixed within the scope, you do not pay for this fixed scope and you keep the findings. If a safe way back into the server does not exist, we stop before any change.
When it fits, and when we stop
It fits when
- You have a provider console, rescue mode or snapshot restore that works even if SSH stops working
- The server runs Debian or Ubuntu with systemd and apt
- You can name every administrator and give a public key for each, and list the ports that must stay open
- You can give a short window to test a second login before the first session is closed
We stop and tell you if
- There is no way back into the server if SSH or the firewall is misconfigured
- There are signs of compromise, such as unknown accounts, unknown processes or unexpected outgoing connections
- A service on the server needs password SSH logins and cannot move to keys
- The server is not Debian or Ubuntu: other distributions use other tools and are quoted separately
What could go wrong
The change set records each file before and after. Restoring the saved SSH configuration and reloading the service, disabling the firewall, and removing the automatic-update settings each return the server to its earlier state. The provider console or snapshot is the route back if a mistake blocks SSH.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A mistake in the SSH or firewall change locks you out of the server. | Require a working console or snapshot route first, keep the first session open while a second login is tested, and apply the firewall only after the SSH allow rule exists. |
| A drop-in file overrides the setting that was changed, so the file looks right but the effective setting is not. | Verify the effective settings with the SSH test mode, not the file. OpenSSH uses the first value it reads for a setting. |
| An automatic reboot interrupts a service at a bad time. | Automatic reboot is off unless you choose it. If you do, you pick the time, and the handover states what restarts. |
An independent reviewer reads the SSH and firewall changes and the order they are applied in, and confirms that a second login works before the first session is closed. You approve each live change.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the administrators, the ports to keep open, the reboot policy and the recovery route in writing
- Rehearse the changes on a snapshot copy of the same operating system release
- Read the effective SSH configuration, including any included drop-in files, and set key-only login so the order of files cannot undo it
- Add the firewall rules, with the SSH allow rule in place before the firewall is switched on, and check IPv4 and IPv6
- Enable automatic security updates and run the dry run
- Independent review, then a second login is tested before the first session closes; the outside port check and update checks follow
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, the total price, a start window and a delivery date before you accept. Work starts only after agreed inputs, secure access, any licences and necessary permissions are in place. Hosting, platform and supplier charges are excluded unless the written quote includes them. No charge or booking is created by an enquiry.
Need to keep it working?
To keep the server patched and reviewed afterwards, ask about the monthly server patch and review service. This job is a one-time baseline.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Canonical documents how unattended upgrades are configured on Ubuntu, including a dry run, which a technical team can follow itself. ubuntu.com
- Many providers offer a network firewall in their control panel that you can set up without touching the server.
Questions
Is this a security audit?
No. It sets and verifies three specific controls on one server. It is not a penetration test, a vulnerability scan or a compliance certification, and we do not give a certificate.
What if I lock myself out?
That is why a provider console or snapshot is required first, and why a second login is tested before the first closes. If neither exists, we stop before changing anything.
Will the server reboot by itself?
Only if you choose it. Automatic reboot is off by default, and the handover states when a restart is pending.
Do you need my private key?
Never. We need public keys. You keep every private key.
Send an enquiry
Send us
- The provider, the operating system release and whether a console or snapshot restore exists
- The ports that must be reachable, for example 22, 80 and 443
- How many people log in over SSH and which of them need administrator rights
- Do not send passwords, private keys or server logins in the first enquiry
Later, once you agree
- One public key per administrator (never a private key) and the name of the person who owns each
- A rehearsal on a snapshot copy, or a time-limited administrator session that you open and close
- The reboot window, and the address that should receive update reports if you want them
- A company-controlled secure handoff agreed before access: no live passwords, keys, private code or customer records by ordinary email.
You own the server and every key. We never receive a private key. We rehearse the changes on a copy of the same operating system release, then either your administrator runs the change set and sends the output, or you open a time-limited administrator session that you close afterwards, agreed in writing. We keep an existing session open while a second login is tested.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “linux-baseline-ssh-keys-firewall-updates-verified” as the subject.