Overview
Set up a fresh Ubuntu VPS with verified access, deliberate network exposure and a recovery plan. This written companion follows the narrated video; it does not claim a live server was configured during production.
Know which machine you are using
A terminal is the application that displays a shell, while the shell interprets commands. Opening Terminal on your Mac does not automatically connect to Ubuntu. Check the username, hostname, and working directory before changing files. After SSH connects, commands run on the server until you exit that session. Keep local and remote windows clearly labelled. This simple habit prevents uploading the wrong file or changing permissions on the wrong machine.
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.
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.
Create your administrator account
Create a named administrator account rather than doing all future work through a shared initial login. This walkthrough uses admin as the account name; use your own consistent name if preferred. Add the account to the appropriate administrative group and record how its password and recovery are managed. Do not assume the provider permits password-based SSH just because a local password exists. We will install and test a dedicated public key before depending on this new account remotely.
Check privileges before changing access
Inspect the new account and its intended administrative policy while the initial access path is still available. Confirm that the account exists and belongs to the expected group. A policy listing helps identify configuration mistakes, but it does not prove that the person can authenticate or complete a sudo prompt remotely. The next steps create and install the key, followed by a separate login test. Keep the provider console available throughout this sequence.
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.
Create a dedicated key on your own computer
Generate the client key on the computer from which you intend to connect. Use a dedicated filename and check that it does not overwrite an existing identity. Protect the private key with a passphrase where appropriate. The public file can be installed on the server, while the private file stays under your control. A key passphrase protects the local key file; it is different from the remote account's password and may still be requested when you connect.
Install only the public key
Install the public key for the account you actually intend to use. Some clients provide a helper that appends the public key through an existing authenticated connection. If that helper is unavailable, use the provider console or a working login to append the public line manually. Preserve existing authorized entries unless you deliberately intend to revoke them. Keep the public key on one complete line and avoid copying extra labels or terminal prompt characters.
Check the server-side key permissions
The server must be able to trust the account's SSH directory and authorized-key file. Check that they belong to the intended user and are not writable by unrelated users. The example assumes the authorized-key file already exists after installation. If ownership is wrong because an administrator created it, correct that specific path deliberately. Do not loosen permissions globally. Server logs often explain why an apparently correct public key was rejected.
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.
Create a readable SSH alias
A host entry in the local SSH configuration keeps the connection details together. Give it a memorable alias and specify the correct username and private-key file. Use that alias with both SSH and file-transfer commands. Restrict access to the configuration file when it contains sensitive operational details, and avoid committing personal connection settings into a public repository. Test the alias before replacing commands in a deployment workflow that other people rely on.
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.
Understand services before adding applications
A system service can run independently of your interactive terminal. Inspect the installed SSH service and learn how the system reports active, failed, and enabled states. A service being enabled for startup does not prove that it is currently healthy. At this stage, you do not need to install a web runtime or database merely to administer the server. Add those components later when you have a specific application and a documented reason for exposing it.
Check time and basic operating health
Check the clock, available memory, disk capacity, and basic uptime before adding application workloads. Accurate time helps with certificates, logs, and authentication. A very small VPS may have limited room for builds and package updates even when an idle server appears healthy. Record the baseline so later changes can be compared with something meaningful. These commands inspect state; they do not establish that a website is available or that a backup can be restored.
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.
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.
Choose a backup method for the current server
Choose a backup approach that matches what exists on the server today. On a fresh machine, preserve configuration and recovery information without copying private credentials into an unprotected archive. Provider snapshots can be useful, but understand their retention and restore scope. When an application and database are added later, establish application-consistent backups as well. Keep a protected recovery copy outside the same failure domain rather than relying only on files stored beside the original data.
Restore a small test before relying on backups
Test the backup method with a harmless file and restore it to a separate location. Confirm the contents and permissions without overwriting the working configuration. A successful archive creation message is not the same as a successful restore. If you plan to depend on a full-server snapshot, understand how to restore it to a separate test instance and how networking or host identity may change. Keep the recovery instructions somewhere accessible when the VPS itself is unavailable.
Document the handover baseline
Finish the initial setup with a short operational handover. Record which account should be used, who owns the client key, which ports should be exposed, and how updates and backups will be maintained. Keep sensitive recovery material in an appropriate protected location, separate from a public tutorial or repository. List application installation as a later step rather than pretending the fresh VPS already hosts a complete service. A documented baseline makes future troubleshooting and security reviews much easier.
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
See CodeKits development services for implementation help.