Modern SSH client family for Android, Linux, macOS, Windows, and BSD. Open-source and privacy-focused.

Security Best Practices

How to use TabSSH securely. For the mechanism-level details (Keystore, AES-256-GCM, FLAG_SECURE, etc.) see the top-level Security page.

Mobile + Desktop: the principles below apply to both clients. Mobile-specific mechanisms (Android Keystore, FLAG_SECURE, app-lock) are noted inline; desktop counterparts (OS keychain, system lock) follow the same security stance.

🔑 Use SSH Keys, Not Passwords

  • Generate an Ed25519 key in TabSSH (or import one). Add a passphrase.
  • Copy the public key to ~/.ssh/authorized_keys on each server.
  • Disable password auth on the server (PasswordAuthentication no in sshd_config) once keys are working.
  • If a server insists on passwords, use Save password in TabSSH so it's encrypted in the Android Keystore — don't type it from memory each time.

🔐 Verify Host Keys on First Connect

  • The first-connect dialog shows the server's SHA-256 fingerprint and an emoji visual fingerprint.
  • Compare it to what you see on a desktop you trust (run ssh-keyscan host | ssh-keygen -lf -) before tapping Accept Always.
  • If you're connecting over an untrusted network for the first time, this verification is the only thing standing between you and a MITM.
"Host key changed" on a host you've already accepted is the MITM warning. Treat it as a possible attack until proven otherwise. The benign explanation is usually "the server was reinstalled" — verify with the server admin before accepting.

📵 App Lock

If your phone is unlocked, anyone with it can open TabSSH and your saved connections. Add a layer.

  • Biometric unlock — fingerprint or face for app and credential access. Settings → Security.
  • PIN code app lock (Wave 3.2) — separate PIN if you'd rather skip biometrics, or want a second factor on top.
  • Auto-lock after inactivity — configurable timeout (1m, 5m, 15m, 30m, 1h). Re-prompts when you return.

📸 Screenshot & Recents Protection

  • Sensitive activities (passwords, key import, PIN entry) set FLAG_SECURE, which blocks screenshots, screen recording, and the Recents thumbnail.
  • The terminal itself can also be flagged secure if you enable it in Settings → Security.

☁️ Cloud Sync Encryption

  • Sync content goes through AES-256-GCM with PBKDF2 (100,000 iterations) before it leaves the device.
  • Your storage provider (Nextcloud, Dropbox, Google Drive, …) only ever sees encrypted blobs — they cannot read your hosts, keys, or passwords.
  • Pick a strong sync password. If you forget it, the encrypted blob cannot be recovered. Write it down somewhere safe.
  • SAF means TabSSH never has direct API credentials to your cloud account — that lives with the storage provider's app.

🔧 Cloud Host Import Tokens

If you use the DigitalOcean / Hetzner / Linode / Vultr inventory import:

  • Use read-only API tokens where the provider supports them.
  • Tokens are stored in the Android Keystore under cloud_token_${id} — never in TabSSH's SQLite database.
  • Revoke tokens from the provider's web UI if your phone is lost — TabSSH can't auto-rotate them.

🐛 Debug Builds vs Release Builds

  • Debug builds auto-enable verbose logging (incl. an ANR watchdog and crash reporter). They're useful for testing but spend a small amount of CPU on instrumentation.
  • Release builds default to logging off. Enable per-feature in Settings → Logging if you need to capture an issue, then disable when done.
  • Don't run dev / pre-release builds against production hosts if you can avoid it. Run stable for production, dev for play.

📝 Reporting Vulnerabilities

Use GitHub's private vulnerability reporting on the relevant repo's Security tab:

  • Don't open public issues for security bugs.
  • Include reproduction steps and impact assessment.
Back to Documentation Top-level Security →