Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.rafftechnologies.com/llms.txt

Use this file to discover all available pages before exploring further.

Updated May 8, 2026 Every way of getting into a Raff VM combines two layers:
LayerWhat it doesExamples
CredentialsProve who you are to the OSSSH key, root/Administrator password
TransportCarry the session from your machine to the VMBrowser terminal, VNC console, direct SSH, direct RDP
Pick the credential at create-time; pick the transport whenever you connect. They’re independent — you can switch transport without changing credentials and vice versa.

​
Credentials

The two credential types Raff supports. Public-key authentication. You upload the public key once at the account level — the dashboard’s SSH Keys section in the left nav — and reference it whenever you create or reinstall a VM.
  • The private key never leaves your machine.
  • Multiple keys per account (one per laptop, per CI runner, per teammate).
  • Adding a key after VM creation: log in via VNC and append to ~/.ssh/authorized_keys.
  • Keys are unaffected by reset password — they keep working even after a password rotation.

​
Password (root / Administrator)

Generated at create-time (or you set your own). The platform never displays the password in the dashboard — it’s always emailed to your account address.
  • Linux — root user.
  • Windows — Administrator. Required for RDP; SSH key isn’t an option for the in-built remote-desktop flow.
  • Recovery: Send to Email (sends the current password) or Reset password (generates a new one).
  • Reset on a running VM triggers a hard reboot to apply; on a stopped VM it lands on next start.

​
When to use which

ScenarioCredential
Linux, daily work, multi-userSSH keys (preferred)
Linux, you locked yourself outPassword (recover via email)
Windows, anythingPassword (Administrator)
Automated provisioning (Terraform, scripts)SSH keys
You can have both on the same VM — keys for routine access, password as the recovery fallback. This is the recommended posture for production Linux VMs.

​
Transports

Five ways to actually reach the VM.

​
1. Browser SSH terminal — in-app

Click Console on the VM detail page. Opens a web terminal that’s already authenticated as root. No client install. Best for quick checks. Auto-selected by the dashboard when:
  • VM has a public IPv4 and SSH is enabled inside the OS.

​
2. VNC console — in-app, graphical

Same Console button, different rendering — the dashboard auto-switches to VNC when the SSH terminal can’t work, OR when the VM is Windows. VNC connects through the hypervisor, not the network, so it works even if SSH is broken or the VM has no public IP. Auto-selected when:
  • The VM has no public IPv4 (private-only VPC), or
  • SSH is disabled or its daemon isn’t running, or
  • The VM is Windows (in-app RDP isn’t offered; VNC is the in-app option).
VNC sessions have a visible Expires timer — re-open the console when it counts down to extend.

​
3. Direct SSH — your terminal

Run ssh root@<public-ipv4> (or ssh -i <key> ...) from your local terminal. Best for daily Linux use, scripts, file transfer (scp / rsync), port forwarding.
  • Requires public IPv4 + SSH enabled.
  • Tightly tied to the security group — port 22 must be allowed from your IP.
  • Use any SSH client: macOS/Linux native ssh, Windows OpenSSH (Win10+), PuTTY.
See Connect via SSH.

​
4. Direct RDP — your client

For Windows VMs. Connect with mstsc (Windows), the Windows App (macOS / iOS / web), Royal TS / Royal TSX, Jump Desktop, FreeRDP (xfreerdp), or Remmina.
  • Requires public IPv4 + TCP/3389 allowed in the security group.
  • Username Administrator, password from the Credentials card.
See Connect via RDP.

​
5. Direct VNC — not exposed

VNC is only available through the in-app console (transport #2). Raff doesn’t expose VNC over the public network; there’s no port to point a desktop VNC client at.

​
How the Console button decides

When you click Console on the VM detail page: 
┌─ VM is Linux?
│   ├─ Public IPv4 + SSH enabled? ──→ Browser SSH terminal
│   └─ Otherwise                  ──→ VNC console
└─ VM is Windows?                 ──→ VNC console (always)
You don’t pick — the dashboard chooses based on what’s actually reachable. This makes the Console button safe as your “I just need to get in” path: it always works as long as the VM is up.

​
Credentials × transports — quick table

Credential ↓ / Transport →Browser SSHVNCDirect SSHDirect RDP
SSH key✅ (auto-login)❌ (VNC needs password)✅n/a
Password (Linux)✅ (auto-login)✅✅n/a
Password (Windows)n/a✅n/a✅
A few non-obvious points:
  • Browser SSH auto-logs in as root using the VM’s stored credentials, even if password auth is disabled at the SSH daemon level — it goes through a privileged path.
  • VNC always requires the password, even with SSH keys configured. For Linux, this means you should keep a password set as a recovery option, not just keys.
  • Windows in-app access is VNC only — direct RDP is the production-quality path; VNC is for recovery.

​
Recovery scenarios

Walk through which combination to use when things go wrong.
SituationFirst tryIf that fails
Forgot SSH key, password worksDirect SSH with password (if enabled)VNC + password
Forgot password, key worksDirect SSH with keyVNC after Reset password
Lost bothReset password, then VNCFactory reset (preserves volumes/backups)
SSH config locked you outVNC, fix sshd_configRecover a locked-out VM
Firewall rule locked you outVNC, fix UFW/firewalld(same)
No public IPv4VNC(only option)
OS won’t even bootVNC + GRUB single-userFactory reset

Connect via SSH

All three Linux transports in detail.

Connect via RDP

Windows VNC + direct RDP clients.

Reset password

Recover a lost root / Administrator password.

Recover a locked-out VM

Five-tier recovery ladder.
Last modified on May 8, 2026