ScaleToad guides · VM access

Your server.
Your way to sign in.

SSH gives you a secure terminal on your VM. Use an SSH key by default, or explicitly allow a password. Root access is a separate choice.

Recommended default

1. Add an SSH key

A key has two files: a public key you give ScaleToad and a private key that stays on your computer. Never paste a private key into the panel, a chat, or a support ticket.

Open your terminal. Use Terminal on macOS/Linux or PowerShell on Windows with the OpenSSH client installed.
Create a key if you need one. Run ssh-keygen -t ed25519. Choose a filename you can recognize. If that file already exists, answer n to overwriting it and choose another name. A passphrase is recommended; store it safely.
Open the file ending in .pub in a text editor. It is usually id_ed25519.pub inside your user folder's .ssh directory, unless you chose another name. Copy its complete, single line.
Save it in Keys & secrets. Give the SSH key a useful name, such as “My laptop,” then select it when configuring a new VM. You can also paste the public key directly into the VM form.

Already have an SSH key? Use its public .pub file; there is no need to replace it. Saving or deleting a key in the panel does not automatically change an existing VM.

2. Connect to your VM

Open your VM in Servers and copy the SSH command from its connection card. Keep the username, hostname, and port exactly as shown.

ssh -p 30123 scaletoad@ssh.example.com

This is an example, not a working address. Shared IPs use a different public port for each VM. Do not replace it with port 22. Use root only if you enabled direct root login; the scaletoad user can otherwise administer the VM with sudo.

Verify the server before signing in. On the first connection, compare the SSH host-key fingerprint with one obtained through a trusted operator or an already trusted console/session. Do not accept an unknown or changed fingerprint blindly. If you cannot verify it, pause and ask the operator.

My key has a custom filename, or SSH keeps asking for it

Add -i /path/to/your/private-key to the copied command, replacing that example path with your local private-key file, not its .pub file. SSH reads the private key locally; you do not upload it.

A local SSH agent can remember an unlocked key for your session. If an agent is running, use ssh-add /path/to/your/private-key. Setup differs by operating system. Your key's passphrase unlocks the local key; it is not your VM password or your ScaleToad account password.

3. Prefer a password? Explicitly allow it.

For a new VM, turn on Allow password login in the access options. Choose and confirm a unique password of 16–128 characters (also at most 128 UTF-8 bytes). A long password-manager-generated password or ASCII passphrase is a good fit. Never reuse your ScaleToad account password.

Keys remain the default. With password access off, provide at least one SSH key.
You can keep both methods. If you select a key and explicitly allow a password, either one can sign you in. Password-only access is also allowed after explicit opt-in.
Root is separate. Enable direct root login only if you want to sign in as root. The password is set for your selected SSH account: root or scaletoad, not your ScaleToad website account.
Keep the password somewhere safe. It will not be shown back in your quote or connection card. Type it only when SSH prompts; do not place it in a command, URL, or support message.

Password login makes your VM susceptible to password guessing. Use a unique, strong password and appropriate network restrictions. A shared IP does not make weak passwords safe.

Access choices apply to the new VM. They do not change existing VMs, the shared gateway, or ScaleToad's infrastructure. Buying a dedicated IP does not grant extra privileges or automatically enable password login.

Self-service rebuild is unavailable for password-enabled VMs until it can safely collect a fresh password. This prevents a rebuild from restoring an old password you changed inside the VM.

Already have a VM?

Change its access from an existing, trusted SSH session. Keep that session open until a second login succeeds. Confirm an operator-assisted recovery route before editing SSH; a browser console or automatic password reset may not be available.

Add a key to an existing VM

Sign in as the account that should receive the key. In that account's home directory, create .ssh if missing and set its permissions to 700. Edit .ssh/authorized_keys and append the complete public-key line without replacing existing keys; set that file's permissions to 600. Both must belong to that account.

Test the added key in a second terminal before removing any old key. Adding a key for scaletoad does not automatically authorize it for root.

New password-enabled VMs restrict SSH to scaletoad, plus root when selected. To add another SSH account, an administrator must deliberately update AllowUsers in the effective SSH settings, then validate and test as described below.

Advanced: enable or change a VM password safely

These instructions concern Linux VMs running OpenSSH. Review your image's documentation if its configuration differs. If already signed in as root, omit sudo where appropriate.

Set the intended account's password. Use passwd to change the current account's existing password. An administrator can use sudo passwd scaletoad to set the named account's password, or sudo passwd root only when deliberately enabling root password access. Enter the password at the prompt.
Back up and edit the effective SSH settings. Current ScaleToad images use /etc/ssh/sshd_config.d/00-scaletoad.conf. Preserve its current content before editing with sudoedit. Older images may have a different file. Most OpenSSH settings take the first value encountered; adding a later 99-*.conf file may not override an earlier restriction.
Allow the intended methods. Update the existing directives, preserving unrelated settings, to allow password or key authentication:

PasswordAuthentication yes
PubkeyAuthentication yes
AuthenticationMethods publickey password
KbdInteractiveAuthentication no
PermitEmptyPasswords no

The space between publickey password means either method. A comma would require both. Keep PermitRootLogin no if direct root access is unwanted, or prohibit-password for root keys only. Set PermitRootLogin yes only if deliberately allowing root to use its password as well.

If an AllowUsers list exists, also add the intended account to it. For example, deliberately enabling root on a VM with AllowUsers scaletoad requires AllowUsers scaletoad root. Keep the currently working account in the list.

Validate before reloading. Run sudo /usr/sbin/sshd -t; fix every error before continuing. Inspect sudo /usr/sbin/sshd -T. If the configuration has Match blocks, use the manual's -C connection parameters to check the actual user and client address, not just global defaults.
Reload the correct service. On Ubuntu, use sudo systemctl reload ssh.service. Other images may name it sshd.service. Do not close the original session.
Test a second login. Add -o PreferredAuthentications=password -o PubkeyAuthentication=no to the copied SSH command to test the password method specifically. If it fails, use the first session to correct or restore the settings, validate again, and reload.

Changing an account password alone does not enable SSH password authentication. Changing SSH authentication does not create a public endpoint or open a firewall. Do not change the guest's SSH listening port to its assigned shared public port; forwarding handles that mapping.

Switch back to keys only

First confirm a fresh key-based login works for the correct account. Then change the effective settings to PasswordAuthentication no, KbdInteractiveAuthentication no, and AuthenticationMethods publickey. Use PermitRootLogin prohibit-password if root keys should still work, or no to disable direct root login.

Validate with sshd -t, reload as described above, and test another key login before closing the first session. A disabled SSH password method does not remove the local account's password or change its console/sudo rules.

Connection failed, or the server's fingerprint changed

Timeout or connection refused: check the VM is running, its connection is ready, and you copied the current host and port. A password change cannot repair unavailable networking.

Permission denied: check the username, selected key or password, and the VM's effective SSH settings. A root login can be disabled while the named sudo user still works.

Host-key warning: stop and verify the new fingerprint through a trusted route. A rebuild or reassigned shared port can change the server behind an address, but that is not a reason to dismiss the warning. Do not disable host-key checking.