Your first SSH session, with a way back.

Collect the access details and recovery path

You need the actual server address, SSH port, login username, initial authentication method and a trusted source for the server’s host-key fingerprint. A chosen hostname in a configurator does not establish DNS or create an account. Obtain these details from the actual service setup, not from assumptions about a Linux image.

Confirm how to reach a console or rescue environment and who can recover access. Check that you can open that recovery route now; do not discover during a lockout that you lack permission or recovery credentials. If no independent recovery path is available, keep access settings unchanged until one is arranged.

The examples use a Bash client terminal on your own computer and an Ubuntu/Debian server. Substitute your real details for builder, port 22 and 192.0.2.10, which is a reserved example address. Commands are instructions to review for your environment; this guide has not connected to or configured an OffVPS server.

Create a client key without replacing an existing one

Your private key stays on the client computer. The matching public key can be installed in the server account’s authorized keys. Neither is the server’s host key: that separate key helps identify the machine you are contacting. Keep the private key and its passphrase out of support messages, repositories and server uploads.

ssh -V
ls -ld "$HOME/.ssh"
ls "$HOME/.ssh/offvps_first_vps" "$HOME/.ssh/offvps_first_vps.pub"

Inspect the paths first. If the SSH directory does not exist, create it with permission 700. If either named key file already exists, choose another name or deliberately reuse your existing key; do not overwrite it. Generate a dedicated key with a passphrase:

ssh-keygen -t ed25519 -f "$HOME/.ssh/offvps_first_vps" -C "first-vps"
ssh-keygen -lf "$HOME/.ssh/offvps_first_vps.pub" -E sha256

The second command displays the public-key fingerprint, not private-key material. The ssh-keygen manual documents key types, output files and fingerprints. Where a managed device requires a different key policy, follow that policy and verify server support. Keep an appropriately protected recovery copy of the private key if your recovery plan depends on it.

Verify the server before authenticating

Through the trusted console or another authenticated setup channel, obtain the fingerprint for the server’s Ed25519 host key. On a server using the standard OpenSSH path, an administrator can inspect the public file with:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256

Compare the full SHA256 fingerprint and algorithm with the first SSH connection prompt. A fingerprint retrieved only through the same unverified network connection is not independent verification. If the server offers another host-key algorithm, obtain that key’s fingerprint rather than comparing unlike values. OpenSSH’s host-key verification guidance explains this comparison.

If the key changes unexpectedly on a later visit, stop. A rebuild may legitimately replace host keys, but verify that event and the new fingerprint through the recovery channel. Do not silence the warning or delete the old known-host entry merely to make the connection succeed.

Install only the public key and open the first session

If your public key was already installed through the authorized setup process, connect directly. Otherwise, use the existing verified access method to add the public key to the intended account. On a client with ssh-copy-id, and only when that initial login method works, this command appends the selected public key:

ssh-copy-id -i "$HOME/.ssh/offvps_first_vps.pub" -p 22 [email protected]

Ubuntu’s OpenSSH guide describes public-key installation and permission requirements. Do not replace an entire authorized_keys file or alter another administrator’s entries. Then open the key-based session:

ssh -o IdentitiesOnly=yes -i "$HOME/.ssh/offvps_first_vps" \
  -p 22 [email protected]

After login, check id and hostname. Confirm the account matches the setup details; a hostname alone is not host-key verification. If your tasks require administration, run sudo -v and establish that this account has the intended privilege path. Keep this first session open.

Prove a genuinely separate second login

Open another client terminal and request a new connection that cannot reuse an SSH connection-sharing socket. Restrict this test to public-key authentication so a password fallback does not hide a broken key setup:

ssh -o ControlMaster=no -o ControlPath=none \
  -o IdentitiesOnly=yes -o PreferredAuthentications=publickey \
  -i "$HOME/.ssh/offvps_first_vps" -p 22 [email protected]

Check id, hostname and, where needed, sudo -v in this second session too. A new terminal alone is insufficient if the client reuses an existing connection. ControlPath=none disables that sharing; see OpenSSH client configuration. Only close the original session after this independent connection succeeds and the recovery path remains available.

Before any later access change

For this first session, leave the SSH port, authentication methods and firewall rules as they are. Before changing them later, save the current configuration and document how to restore it through the trusted console. Confirm a working key login before disabling another method. Keep the first session open while making one reviewed change at a time.

sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T

On systems with this OpenSSH executable path, -t checks configuration syntax and host-key sanity; -T also reports effective settings. Connection-specific Match rules may require -C parameters for the account and address being tested. These checks do not test firewall reachability or prove a new login works. See sshd test modes. Resolve errors before applying or reloading a service configuration, then repeat the independent login check.

Use the failure to choose the next check

• Timeout: confirm the address, port, provider rules and host firewall through the recovery path.
• Connection refused: check whether SSH is listening on the expected address and port.
• Permission denied: check username, selected public key and account key-file permissions from the still-open session.
• Host identification changed: verify the machine and new fingerprint independently before continuing.

Record the verified host-key fingerprint, account, port and recovery procedure in your operating notes. Keep key material private. Once access is repeatable, continue to your first API release or a resource budget for the application.