API Authentication
Every automation request to ZestSSH must be authenticated with an API key. This page covers how keys are generated, used, and managed.
Key Generation
Section titled “Key Generation”API keys are generated in Settings > Automation > Manage API Keys > Create Key.
Key Properties
Section titled “Key Properties”- Length: 48 characters
- Character set:
a-z,A-Z,0-9(62 characters) - Entropy: ~285 bits (
log2(62^48)) - Generator:
Random.secure(), backed by the OS CSPRNG (/dev/urandomon Linux/Android,SecRandomCopyByteson iOS/macOS,BCryptGenRandomon Windows)
Key Metadata
Section titled “Key Metadata”Each key has:
| Field | Description |
|---|---|
| ID | UUID, used internally |
| Label | Human-readable name (e.g. “Tasker - Backups”) |
| Key | The 48-character secret |
| Created At | Timestamp of creation |
| Last Used At | Updated on each successful use |
| Expires At | Optional expiration date |
Expiration
Section titled “Expiration”Keys can be created with an optional expiration date. After the expiration date:
- The key is treated as invalid.
- Requests using it are rejected with an error.
- Failed attempts with expired keys count toward the rate limit.
- The key remains in the list (for audit purposes) until you delete it.
Passing the Key in Requests
Section titled “Passing the Key in Requests”URL Scheme
Section titled “URL Scheme”Include the key as a key query parameter:
zestssh://execute?connection=MyServer&command=uptime&key=abcDEF123...Android Intent
Section titled “Android Intent”Pass the key as an intent extra:
Extra: key → abcDEF123...Security of Transmission
Section titled “Security of Transmission”The API key is passed locally on the device --- it does not traverse the network. URL schemes and Android intents are inter-process communication (IPC) mechanisms within the same device.
However, be aware that:
- Other apps on the device could potentially intercept deep links if they register the same URL scheme (Android prevents this with app signing verification).
- Intent extras are visible to apps with
READ_LOGSpermission on rooted devices. - Tasker profiles that contain API keys store them in Tasker’s configuration files (plaintext on disk if the device is rooted or backed up).
Key Validation
Section titled “Key Validation”When a request arrives:
- Rate limit check: If the account is in lockout (5 consecutive failures), reject immediately.
- Hash and compare: The submitted key is SHA-256 hashed and compared against stored key hashes using constant-time comparison to prevent timing side-channel attacks.
- Expiration check: If the matched key has expired, reject.
- Mark used: Update the
lastUsedAttimestamp atomically with the validation.
The hash-then-compare approach means the raw key is never compared byte-by-byte, eliminating timing information that could help an attacker narrow down the key value.
Rate Limiting
Section titled “Rate Limiting”| Condition | Effect |
|---|---|
| Failed validation | Increment failure counter |
| 5 consecutive failures | Lock out all automation for 60 seconds |
| Successful validation | Reset failure counter to 0 |
| Lockout expires | Counter resets on next attempt |
The lockout state is persisted to secure storage, so it survives app restarts.
Key Rotation
Section titled “Key Rotation”To rotate a key without downtime:
- Create a new key with a descriptive label (e.g. “Tasker - Backups v2”).
- Update all automation tasks (Tasker profiles, Shortcuts, etc.) to use the new key.
- Verify the new key works by running a test automation.
- Delete the old key.
There is no limit on the number of active keys. Creating a new key does not invalidate existing keys.
Key Revocation
Section titled “Key Revocation”To immediately revoke a key:
- Go to Settings > Automation > Manage API Keys.
- Swipe or tap the delete action on the key.
- The key is removed from secure storage. Any future requests using it are rejected.
Revocation is immediate. There is no grace period.
Display and Masking
Section titled “Display and Masking”In the API key management UI, keys are displayed in masked format: the first 4 characters, 8 dots, and the last 4 characters (e.g. abcD........EF12). The full key is only visible once at creation time. If you lose a key, create a new one --- there is no way to recover the full key from storage.
Best Practices
Section titled “Best Practices”- Create separate keys for each automation tool or purpose. This limits the blast radius of a compromised key.
- Set expiration dates for keys used in temporary or time-limited automation.
- Review last-used timestamps periodically. Keys that have not been used in months may be candidates for revocation.
- Do not embed keys in shared files. If you export Tasker profiles, remove or placeholder the API keys first.
- Enable app lock (biometric or PIN) in ZestSSH to prevent unauthorized key creation on a stolen device.