Zero-Trust. Zero-Knowledge.
Absolute infrastructure security.
Your connection credentials, private keys, and terminal logs form the keys to your kingdom. Here is how Ultron SSH isolates, encrypts, and guarantees they never leave your control.
Local Sandbox (On-Device)
All critical operations run locally. Sensitive keys are stored in a local encrypted database. Raw private keys and passwords reside in memory only and are never saved in plain text.
- AES-256-GCM local storage
- Context-isolated Electron process
- Scrypt-derived encryption key
Supabase Cloud Sync
For Pro tiers, data is encrypted locally using your Master Password before being synced. The server receives only high-entropy ciphertext. We cannot read your keys.
- Row-Level Security (RLS)
- Zero-knowledge decryption
- Multi-tenant tenant separation
Remote Infrastructure
Direct connections to your VMs, Docker sockets, and cloud servers. Sessions are tunneled directly from the desktop shell. No intermediary relay servers.
- Direct SSH tunnels & key exchanges
- Local Docker socket forwarding
- Native VMware / ESXi commands
On-Device Local Encryption
Zero credentials hit the cloud in plain text.
Ultron SSH operates on a strict zero-knowledge model. All critical authentication components, including SSH private keys, server passwords, snippets, and environment variables, are encrypted locally on your macOS system before being committed to storage.
Cryptographic parameters
- Encryption Standard: AES-256-GCM (Advanced Encryption Standard with Galois/Counter Mode), offering both privacy and integrity verification for all data segments.
- Key Derivation Function:
scryptis used to stretch your app master password, adding substantial protection against brute-force and hardware-accelerated dictionary attacks. - Entropy: Each write operation generates a unique, cryptographically random Initialization Vector (IV), preventing pattern detection.
When Cloud Sync is enabled, the database syncing mechanism pushes only the encrypted ciphertext envelope to our Supabase database. Because we do not store, receive, or know your Master Password, it is cryptographically impossible for us or any third party to decrypt your credentials.
Supabase Multi-Tenant RLS
Enforced PostgreSQL isolation policies.
To host sync configurations and handle user account states securely, we run a robust database architecture backed by Supabase. We protect this architecture through rigid server-side database access controls:
Database guardrails
- Row-Level Security (RLS): Every PostgreSQL table has RLS policies enabled. All queries must resolve against verified user authentication claims.
- Strict Auth Policies: The database engine rejects any request whose user ID claim does not match the unique PostgreSQL row owner ID (
auth.uid() = user_id). - Zero Bypass: All serverless edge handlers and API calls run under least-privilege configurations, guaranteeing that user tenants can never read, modify, or list other users' database records.
This architecture ensures that even in the hypothetical scenario of a public API token leakage, the database blocks unauthorized cross-account lookups natively.
Electron App-Level Hardening
Sandboxed context with zero-node rendering.
Electron apps require strict separation between remote web resources and the underlying host operating system. Ultron SSH is compiled using secure-by-default Electron patterns:
Electron isolation details
- Renderer Sandboxing: All renderer windows are explicitly sandboxed. If an attacker somehow compromises the UI layer, they cannot run arbitrary node scripts on your OS.
- Context Isolation Enabled: We isolate the execution context of the main UI from preload scripts. The rendering page can only communicate with the backend via explicit APIs.
- Node Integration Disabled: The renderer has no direct access to Node.js modules like
fsorchild_process. - Audited IPC Bridge: Inter-Process Communication (IPC) is strictly bound to a limited list of safe, strongly typed methods exposed through the preload bridge (
contextBridge.revealToMainWorld).
This combination of sandbox rules protects the macOS host, preventing remote code execution (RCE) vectors.
Are my server connection credentials transmitted to Ultron SSH servers?
No. All credentials (passwords, private keys, host addresses) are stored locally on your machine. If you enable Cloud Sync, they are encrypted client-side using your Master Password before sync. We never receive or store your Master Password, so we have no way to view your raw credentials.
How does the integrated terminal AI communicate with LLMs?
Ultron SSH does not run intermediary proxy servers for your AI requests. Instead, it follows a Bring-Your-Own-Key (BYOK) model. The client communicates directly and securely with your selected AI provider (e.g., OpenAI or Anthropic endpoints) from your machine, utilizing the API keys you provide locally.
Is the app signed and notarized by Apple?
Yes. Every release of the Ultron SSH macOS desktop application is fully signed with an active Apple Developer Certificate and notarized by Apple. This ensures that the application is free of known malware and passes Gatekeeper checks without security warnings.
How are hypervisor and Docker actions executed?
All VMware ESXi, XCP-ng, and Docker interactions occur locally over the secure shell connections you establish. Power commands or resource metric polling are sent directly to the instance, utilizing either SSH channels or local/remote socket tunnels.
