Overview
SSH Keys and SCP for Your First VPS. 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.
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.
Navigate using paths
An absolute path identifies a location from the filesystem root, while a relative path starts at your current directory. The home directory is different from the root directory. Use print working directory whenever the location is unclear. Listing with hidden entries helps explain why configuration files beginning with a dot may not appear in a normal listing. Tab completion reduces typing mistakes, and quoting a path keeps spaces from being interpreted as separate arguments.
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 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.
Inspect permissions and ownership
File permissions control access for the owner, group, and other users. Understand the ownership shown by a detailed listing before changing permissions. A private notes or key file may need owner-only access, while directories also need traversal permission to reach their contents. Making everything writable is not a reliable fix for an ownership problem. Apply the narrow change required by the workflow and verify that the intended user can perform the operation afterward.
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.
Upload a file with SCP
Run the upload command on the machine that holds the source file. Read it from source to destination: a local file is copied to a path on the remote account. Begin with a small disposable file and inspect it on the server before uploading a large project. The destination may overwrite a file with the same name. Modern OpenSSH SCP uses SFTP for transfer, so avoid assuming that every legacy remote-shell wildcard example behaves identically.
Download and verify a file
To download, reverse the source and destination roles. Choose a clear local filename so you do not unintentionally replace an existing file. For a transfer that needs integrity verification, calculate a checksum for the corresponding source and destination and compare the values. A matching checksum confirms identical bytes, not that the contents are safe or came from the right publisher. Authentication and trusted source selection remain separate parts of the workflow.
Copy directories and understand ports
Recursive copying includes the directory contents, so inspect the source before uploading it. Exclude private keys, environment files, and unrelated data from a deployment package. SSH uses a lowercase option for the destination port, while SCP uses uppercase P. These examples do not change the server port; they only connect to a port that must already be listening and permitted by the network. An alias can reduce mistakes by keeping that detail in one place.
Learn from the local manual
The manual installed on your machine describes the version you actually have. Use it to check options before copying a command written for another operating system. You can search within a manual page and leave the pager with the usual quit key. Error messages often identify an unsupported option or missing argument. Treat those messages as useful evidence and compare the local command with the documented example rather than repeatedly guessing a new flag.
Expect macOS and Linux differences
Many command names exist on both macOS and Ubuntu, but their options are not always interchangeable. macOS commonly includes BSD-derived utilities, while Ubuntu commonly supplies GNU versions. Package managers and service managers also differ. Confirm the operating system and read the local manual for scripts that modify files. Do not install random replacements just to make an unfamiliar command run before understanding why the example assumes a different platform.
Diagnose access failures by layer
Different errors point to different layers. A timeout often involves routing, filtering, or an unavailable destination. A refused connection usually means the address responded but the expected service did not accept it. Permission denied points toward authentication or account policy. Use verbose client output and relevant server logs together. Redact sensitive details before sharing diagnostics, and avoid changing firewall, key files, and server configuration simultaneously because that makes the cause harder to identify.
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.
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.
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.
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.