Overview
Secure Ubuntu Server Without Losing Access. This written companion follows the same sequence as the narrated video. It explains the workflow and validation steps; it does not supply a complete production application or claim a live deployment was performed.
Inventory a new server
Begin by identifying what was actually provisioned. Record the Ubuntu release, architecture, account, network interfaces, and available storage. Provider images may include users, SSH configuration, and management agents that differ from a stock installation. Keep an inventory of deliberate changes rather than assuming every guide begins from the same baseline. A fresh machine is a good opportunity to establish predictable access, updates, backups, and monitoring before it becomes responsible for customer traffic.
Prepare an independent recovery route
Before changing remote access, make sure you have a recovery route outside the SSH session you are about to modify. A provider console or documented rescue process can help when a firewall or authentication change blocks access. Record the intended username and port. Keep the working session open while testing a new connection. An existing connection continuing to work is not proof that a new login will succeed under the changed settings.
Update with a recovery plan
Refreshing the package index and upgrading installed packages are different operations. Review the proposed changes and make sure the server has enough space to complete them. A fresh setup usually provides a convenient maintenance window, but verify how to reconnect after a reboot before restarting. On an established service, coordinate interruptions and recovery. Do not blindly remove packages or reboot simply because a copied command sequence includes those actions after every update.
Verify the server identity
SSH identifies the server with a host key and identifies you with a separate authentication method. On the first connection, compare the host fingerprint with a trusted provider console or another independent source. A key collected from the same untrusted network path is not independent verification. If the host key changes later, investigate whether the server was legitimately rebuilt. Do not automatically remove the warning simply to make the connection proceed.
Prove that key authentication works
Test a new connection that explicitly selects the intended private key and does not fall back to the server account password. You may still be prompted for the private key passphrase. Confirm the remote username and, where needed, administrative access. Keep the original session open throughout this check. Only after the independent login succeeds should you consider disabling an older authentication method, because a familiar prompt can otherwise hide an unintended password fallback.
Disable password login only after testing
Password authentication and keyboard-interactive authentication are separate settings. Review the server's included files and matching rules before changing them, especially if the machine uses multi-factor or centrally managed access. Keep a working non-root account with the administrative privileges you need. Validate the effective configuration and test another new connection before closing recovery access. Disabling root login without a functioning alternative account can lock you out just as effectively as an incorrect firewall rule.
Validate and reload SSH configuration
Syntax validation catches malformed configuration, while effective configuration inspection helps reveal which included values actually apply. Matching rules may require testing a specific connection context. Use the service management command appropriate to the installed Ubuntu configuration, and understand whether socket activation affects listener changes. Reload authentication settings only after validation succeeds. Test a completely new login afterward; the old session remaining open is useful for recovery but is not a successful acceptance test.
Allow SSH before enabling a firewall
A host firewall and a provider firewall can both affect access. Permit the verified SSH listener before enabling a restrictive policy, and keep a recovery console available. Do not assume the default port when the image has been customized. Test a new connection from outside the server after the change. Review IPv6 as well as IPv4. Open application ports only when the intended service needs them, rather than enabling a broad range for possible future use.
Inspect what is publicly listening
Installed software and exposed network services are not the same thing. Inspect listening addresses and ports, then identify the process responsible for each listener. A loopback binding has a different reachability boundary from a wildcard public binding. Containers and provider networking can add further rules, so verify externally when exposure matters. Remove or restrict services you do not need, and retest the applications that depend on them instead of assuming every unfamiliar listener is unnecessary.
Keep service accounts separate
Use separate identities for people and application processes. A website should not normally run as the same privileged account used for server maintenance. Restrict file access and database permissions to the application's actual requirements. Keep secrets outside publicly served directories and out of source control. This separation limits the consequences of an ordinary application failure, but it does not remove the need for secure application code or make a shared server equivalent to several isolated machines.
Keep automatic updates observable
Automatic security updates can reduce the time that known fixes remain unapplied, but the update policy still needs an owner. Inspect what the installed configuration enables and decide how reboots are handled. Review failed updates and package-manager lock conditions rather than repeatedly starting competing upgrade commands. Keep backups and know how to restore service after a bad change. Automation should make maintenance more consistent while preserving enough visibility to detect when it stops working.
Read logs without collecting secrets
Logs help explain authentication failures, service restarts, and resource problems. Select the relevant service and time window instead of exporting the entire journal by default. Timestamps matter when comparing a client error with a server event. Avoid logging passwords, private keys, or complete application secrets in the first place. When troubleshooting with another person, share a short redacted excerpt and the operation that produced it, not a large unrelated archive of sensitive activity.
Rotate a key without losing access
Key rotation should preserve a verified path at every stage. Add the new public key before removing the old one, test it from a separate connection, then remove the retired entry. If a device is lost, revoke the corresponding public key and any other credentials it held. Removing a key does not necessarily terminate sessions that are already authenticated. Review active sessions and the wider account state when responding to a compromised device.
Define what recovery requires
A database dump is only part of application recovery. Identify uploaded files, the application version, configuration, and any keys required to decrypt data. Decide how much recent data loss and downtime are acceptable. Those objectives determine frequency and retention. Keep a written restore procedure that someone other than the original developer can follow, and practise it before an emergency.
Create a protected dump
This optional section applies when the machine already runs a database-backed application. It is not a prerequisite for a fresh desktop or SSH-only server.
Create backups with restrictive permissions and make pipeline failures visible. The single-transaction option is useful for transactional tables, but it isn't a universal consistency guarantee for every engine or concurrent schema change. Avoid running migrations during the dump. Use a protected credentials mechanism rather than placing a password in command history. Record the database version and the exact options needed for your schema.
Verify before marking success
Check the compressed file and record a checksum after the dump completes successfully. These checks detect some corruption and transfer problems; they don't prove that the database can be restored. Write to a temporary filename first and rename only after success so incomplete files aren't mistaken for finished backups. Keep logs useful but free of passwords and sensitive record contents.
Copy backups off the VPS
Copy the verified backup to a separate failure domain. A second directory on the same VPS won't protect against losing the server. Restrict the transfer identity and storage permissions, and decide who can delete historical backups. Consider encryption and immutable retention according to the data's sensitivity. Verify the destination copy and monitor transfer failure instead of assuming that creation on the source is enough.
Restore into an isolated database
This optional section applies when the machine already runs a database-backed application. It is not a prerequisite for a fresh desktop or SSH-only server.
Practise restoration into an isolated target, never over the live database as a routine test. Ensure the dump doesn't contain database-switching statements that would redirect the import unexpectedly. Match required character sets, routines, and compatibility settings. Then verify representative relationships and application queries, not just the command's exit status. A successful decompression check alone can't establish a working recovery path.
Schedule with observable failures
A system timer can schedule a reviewed backup service. The timer is only the schedule; the service still needs a restricted execution context, reliable error propagation, and appropriate credentials. Persistent scheduling can catch a missed run after downtime. Add monitoring for stale backups and failed restores, not just process failure. A daily job that quietly produces unusable files isn't a backup strategy.
Test the application after restore
This optional section applies when the machine already runs a database-backed application. It is not a prerequisite for a fresh desktop or SSH-only server.
Finish the exercise by running the application against the restored data in an isolated environment. Confirm the workflows that matter, including files linked from database records. Measure recovery time and record any missing dependencies or credentials. Retention cleanup should run only after new backups are verified, and should never remove the last known-good recovery point merely because a calendar date changed.
Check processes and resource use
A process is a running program, and resource tools help distinguish a slow application from a full disk or busy machine. Start with read-only inspection and identify the relevant process before stopping anything. Disk capacity and the size of one directory answer different questions. Avoid killing an unfamiliar system process simply because it appears near the top of a list. Record what changed and verify the affected application after any deliberate restart.
Test recovery before calling setup complete
A secure configuration is useful only if the intended workflow remains available and recoverable. Finish with a fresh key-authenticated login, a small round-trip file transfer, and an inspection of public listeners. Confirm the services you intended to expose and verify a backup restore in an isolated location. Record the commands and observed outcomes. Do not describe a server as impossible to compromise; the goal is a maintained, understandable system with explicit access boundaries and a workable recovery plan.
References and next steps
For help implementing or operating the project, see CodeKits development services.