Docs / Security

Encryption overview

NetShell protects your data on three fronts: encrypted SSH transport on the wire, a hardware-backed Keychain for your secrets at rest, and Apple's end-to-end encrypted iCloud Keychain when those secrets travel between your own devices.

The three layers at a glance

Security in NetShell is not a single feature — it is the product of several independent layers that each protect a different stage of your data's life. If you remember nothing else, remember these three:

• In transit — every session is a standard SSH connection, so all traffic between your device and your server is encrypted by the SSH protocol itself.
• At rest — private keys, passphrases, and passwords live in the hardware-backed iOS Keychain, protected by Face ID.
• In sync — those secrets only ever move between your devices through Apple's end-to-end encrypted iCloud Keychain, never a NetShell server.

NetShell is a free SSH client for iPhone, iPad & Mac with no subscription and no telemetry by default — analytics are strictly opt-in. The sections below explain exactly what is protected, where, and what is deliberately never stored.

Encryption in transit (SSH)

When you open a session, NetShell speaks SSH — the same battle-tested protocol that secures servers across the internet. The SSH protocol negotiates a session encryption with the remote host during its handshake, so everything that follows — your keystrokes, command output, file transfers over SFTP, and forwarded ports — travels inside that encrypted channel.

This applies to multi-hop connections too. When you chain through a jump host, each leg of the path is its own encrypted SSH connection; your traffic is never decrypted at an intermediate hop in a way that exposes it on the wire.

Where your credentials live

Every secret NetShell handles — a private key you generate, an OpenSSH key you import, a key passphrase, or a connection password — is written into the hardware-backed iOS Keychain, the operating system's own secure credential store, and protected by Face ID.

NetShell never keeps your secrets in plain files, in app preferences, or in its own database. At connect time it asks the system for an item by name, and the Keychain returns it only after you have authenticated. The app code holds the secret just long enough to complete the handshake.

You can generate ed25519 or RSA keys directly on the device, or import existing OpenSSH keys — including encrypted ed25519 and RSA private keys. In every case the private material lands in the Keychain, not in NetShell's own storage. See the Key vault for the full workflow.

End-to-end encrypted sync

Your secrets are not locked to one device — but they only move between devices you own, and only through Apple's end-to-end encrypted iCloud Keychain. In practice:

• A key or password is encrypted on-device before it ever leaves.
• The keys that protect it are derived from your trusted devices and account security, never from anything NetShell holds.
• Apple relays the encrypted blob between your iPhone, iPad, and Mac but cannot read it — and neither can we.

This requires the same Apple Account on each device, iCloud Keychain enabled, two-factor authentication, and a device passcode. There is no NetShell account, no key escrow, and no sync server we operate. For the full setup and requirements, see Key sync.

Host verification fails closed

Encryption only protects you if you are talking to the right server. NetShell verifies the host's key at handshake time using trust-on-first-use: the first time you connect, you approve the host, and its key is recorded. On every later connection that key must match.

Critically, verification fails closed. If a host is unknown or its key has changed, NetShell stops before sending any credentials — your password or key is never transmitted to a host you have not approved. You decide whether to trust the new key. Read the full behaviour in Host verification.

Host (known-hosts) keys are also handled differently from your secrets: they stay device-local and do not sync. A trust decision belongs to the device that made it, so each device builds and verifies its own known-hosts list.

Defence on the device

Two more layers guard the device itself rather than the connection:

• Face ID auto-relock. NetShell relocks behind Face ID after a period of inactivity, so an unlocked, unattended device does not leave your sessions and vault exposed. See Face ID lock.
• Destructive-command guard. NetShell intercepts high-risk commands before they reach the server — including rm -rf, DROP/TRUNCATE TABLE, git push --force, git reset --hard, shutdown/reboot, kubectl delete namespace, helm uninstall, and pipe-to-bash patterns — and asks you to confirm. See Command guard.

What is and isn't stored

Being precise about storage matters more than slogans. Here is the truthful breakdown:

• Stored, in the hardware-backed Keychain (Face ID): private keys, key passphrases, and connection passwords.
• Stored, device-local only: host (known-hosts) keys — these never sync.
• Synced via iCloud KVS (settings, not secrets): connections, snippets, folders, groups, and tags. See Sync across devices.
• Synced via iCloud Keychain (end-to-end encrypted): passwords and keys take this stronger, separate path instead of KVS.
• Never stored by NetShell: there is no NetShell server holding your keys or passwords, no key escrow, and no telemetry by default — analytics are opt-in only. See Privacy & telemetry.

Putting it together

Plainly stated: your sessions are encrypted by SSH on the wire; your secrets sit in the OS Keychain behind Face ID and travel only between your own devices through Apple's end-to-end encrypted iCloud Keychain; host verification refuses to leak credentials to a host you haven't approved; and a command guard plus auto-relock harden the device itself. NetShell sees none of your secrets, stores none of them on any server, and collects no analytics unless you turn them on.