Security that comes from having nothing to secure

Credential Storage

Passwords, passphrases, and SSH private keys are stored exclusively in the Apple Keychain — hardware-isolated, AES-256 encrypted storage. Keychain items are tied to your device passcode and the Secure Enclave. Even if raw app data is extracted, credentials remain inaccessible without biometric or passcode authentication.

• AES-256 encryption via Secure Enclave
• Biometric-gated access (Face ID / Touch ID)
• Isolated from app sandbox and other applications
• iCloud Keychain sync with E2E encryption (optional)

Data in Transit

All SSH connections use the SSH2 protocol with modern key exchange algorithms (curve25519-sha256, ecdh-sha2-nistp256). GateShell enforces strict host key checking and blocks connections when keys don't match. There are no intermediate servers, relays, or proxies — your session runs directly from your device to your server over an encrypted SSH tunnel.

• SSH2 with Curve25519 key exchange
• Strict host key verification (TOFU pinning)
• No relay for SSH — direct device-to-server connection
• TLS 1.3 for App Store communication (StoreKit)

Data at Rest

Server configurations and snippets are stored in SwiftData and encrypted via Apple's Data Protection API (NSFileProtectionComplete). Session logs, if recording is enabled, are stored in the app container with the same file-level encryption. No data is ever written to shared or unencrypted storage locations.

• NSFileProtectionComplete for all app data
• Session logs encrypted at rest in app container
• No plaintext credential storage — ever
• Data deletion on app removal (no residual data)

Data Collection

GateShell collects zero analytics, zero telemetry, and zero crash reports. There are no third-party SDKs, no advertising identifiers, and no tracking frameworks in the app. We do not know who uses GateShell, how often, or which servers they connect to. This is not a policy — it is an architectural consequence of having no backend.

• No analytics SDKs
• No crash reporting frameworks
• No advertising identifiers
• No user accounts or email database

No Infrastructure to Secure

There are no VPCs, no databases, no user accounts, no load balancers, and no bastion hosts for an attacker to target. Your SSH sessions are direct device-to-server connections. We cannot intercept, log, or observe your traffic because there is nothing of ours in the path to do so — the only service we run is the stateless push relay described below, which never touches a session.

Push Alerts (The One Service We Run)

If you turn on alerts, the agent on your server calls a single relay endpoint we host, which hands the notification to Apple Push. The relay is stateless: it stores nothing between requests, keeps no database, and has no account to sign into. Your device token lives on your own server, and the agent sends it on every call. What passes through is the alert text itself — a line like “CPU above 90% on web-01” — plus that token, over HTTPS. No SSH traffic, no commands, no output, no credentials ever reach it, and nothing about a request is written to a log. Leave alerts off and the relay is never contacted at all.

iCloud Sync (Apple E2E Encryption)

Server configs and snippets sync via iCloud private database with end-to-end encryption. Data is encrypted on your device with keys derived from your Apple ID credentials. Not even Apple can read synced data. This is the same infrastructure that protects Apple Pay, Health data, iCloud Keychain, and Safari passwords.

No Third-Party Services

No analytics providers, no crash reporters, no ad networks, no CDNs, no authentication services. The app talks to your servers over SSH, and to Apple's StoreKit and iCloud — both governed by Apple's own security and privacy guarantees. If you enable push alerts, your server's agent also talks to our push relay, which forwards the notification to Apple Push. That is the complete list.