Start with verified access and a recovery route, then configure individual administration, tested SSH keys, a restrictive firewall, maintained software and independent backups. Apply changes incrementally and verify a new session before closing the old one.
Establish a trusted starting point
Before changing the machine, confirm the expected operating system, access method and recovery route. Verify the SSH host identity through the operator's approved information rather than accepting an unexpected key without investigation. Keep temporary credentials private and replace them through the intended process. Record which person is responsible for maintenance and which recovery options are actually available for this service.
Keep a working administration session open while making access changes. A copied hardening recipe can remove the only usable login when it assumes a different distribution or account layout. Take one change at a time, check its effective result and preserve a route back. The goal is a system you can maintain safely, not a configuration that looks strict but cannot be administered.
Make SSH access deliberate
Create individual administrative access with appropriate privilege rather than sharing one permanent root login. Install and test the intended public key, keeping the private key on the authorised endpoint. The Ubuntu OpenSSH documentation explains server configuration and authentication choices. Read the effective configuration for your distribution, including included files, before assuming that editing one setting has changed the entire service.
Test key access through a second session before changing password authentication or privileged login rules. Ensure the new account can perform the administration it needs. Review any automation that depends on the previous method and replace its access deliberately. A key is an access credential, so use a private storage location and a rotation process rather than leaving copies inside application directories.
Expose the application, not the whole machine
Inventory the listening services and identify which must be public. A web application may need HTTP and HTTPS, while its database can remain reachable only through the intended internal path. Ubuntu documents UFW as a firewall configuration tool, but the useful policy is independent of the tool: permit the required traffic and restrict administration to the approved sources where practical.
Check both host-level and provider-level controls if the service includes them. Before enabling a restrictive rule set, permit the tested administration path and verify access from another session. Do not assume that moving SSH to a different port replaces authentication or patching. Keep firewall rules understandable so future troubleshooting does not lead to opening every port as a workaround.
| Change | Check before applying | Check afterwards |
|---|---|---|
| New SSH key | Correct account and public key | Second key-authenticated session works |
| Restricted firewall | Required service and recovery paths | Public app works; unintended ports are closed |
| Software update | Backup and restart implications | Services restart and application tests pass |
| Service permission change | Required read and write paths | App works without broader system access |
Plan updates as an operating process
Keep the system and application dependencies maintained. Ubuntu's automatic-update guidance describes unattended upgrades, permitted origins and restart behaviour. A third-party repository is not automatically covered just because it was added to the machine. Review what the configured update process actually includes, and give separately installed applications their own maintenance path.
Decide how service restarts and reboots will be handled. Applying a package update does not always mean every running process is using the new code. Use a maintenance window where the workload requires one, and perform a simple application check afterwards. If a package needs manual migration steps, document them instead of disabling all updates indefinitely and forgetting the resulting exposure.
Restrict application access and protect recovery
Run services with the permissions they need, and separate public content from secrets and deployment metadata. A web process should not be able to rewrite every system setting. Keep environment secrets outside publicly served directories and avoid including them in logs, support exports or general backups without an intentional protection policy. Remove unused packages and services when they have no operational purpose.
Maintain an independent backup and test restoring the application into an isolated environment. Restrict backup credentials so a compromised application cannot automatically delete every recovery copy. Monitor disk capacity, backup age and service failures. Logging should answer defined operational questions, with access and retention controlled; it should not become an unlimited copy of sensitive requests.
A first-deployment sequence that stays reviewable
For a new VPS, first verify access and recovery, then establish the administrative account and tested key. Configure the firewall, apply updates and deploy the application under its intended service account. Confirm public behaviour from another environment, check that private files cannot be retrieved and perform a backup restore. Keep notes about each decision and the path for reversing an access change.
Vector VPS, Pulse NVMe and selected dedicated plans present Linux choices in the SwissOctet catalogue. Confirm the chosen image and the division of maintenance work before ordering. No Linux image name proves that hardening, updates or backups are already managed. The baseline is the set of controls you configure, verify and continue to maintain as the project changes.
Your practical checklist.
- Verify the SSH host identity and recovery route.
- Test individual key access in a second session.
- Restrict listening services and firewall rules.
- Review update coverage and restart behaviour.
- Separate secrets from public files and service permissions.
- Test an independent recovery copy.
The details that matter.
Should I disable password login immediately?+
First establish and test the replacement key access and recovery route. Then change authentication according to your supported configuration.
Does an SSH port change replace hardening?+
No. It does not replace strong authentication, restricted access, updates or appropriate account privilege.
Are automatic updates enough for every application?+
No. Check permitted repositories, restart requirements and software installed outside the system's update process.
Go to the source.
These references support the technical concepts in this guide. Follow the current documentation before changing a production system.
- Ubuntu Server: OpenSSH server ubuntu.com
- Ubuntu Server: Firewalls ubuntu.com
- Ubuntu Server: Automatic updates ubuntu.com
Editorial guidance by SwissOctet. Examples are illustrative. Service specifications, available options and contractual conditions must be verified separately.