Security

Security in Termi

Termi is designed as a secure, self-hosted SSH and remote-desktop gateway — security isn't an add-on feature, it's the reason the project exists. This page summarizes the model; the full policy and vulnerability-reporting process live in SECURITY.md in the repository.

Credential encryption

Every stored server credential — host, username, password, private key, key passphrase, and notes — is encrypted with AES-256-GCM before it ever reaches the database. Credentials are decrypted only in memory, for the duration of a connection or an explicit reveal action, and are never written to logs.

An optional user master key, derived with PBKDF2, adds a second encryption layer on top of the system-level encryption for users who want an extra step between a database compromise and readable credentials.

Authentication

• TOTP-based two-factor authentication — compatible with Google Authenticator, Authy, 1Password, and any standard TOTP app
• Passkeys / WebAuthn — passwordless login using hardware security keys, Touch ID, Face ID, or Windows Hello
• Google OAuth as an optional sign-in method
• Session tokens are revocable per device, and brute-force protection locks out repeated failed logins

Sensitive-action re-authentication

Actions that expose credentials — revealing a stored password/key, or exporting your server inventory — require step-up re-authentication (password, 2FA code, or passkey) at the moment of the action, not just a valid session. Every reveal and export is rate-limited and recorded in an audit log.

Network-layer protections

• SSRF protection validates every user-supplied host before Termi will connect to it, blocking attempts to point a "server" at internal/private infrastructure
• CSP (Content Security Policy) and standard security headers are applied to every response
• Rate limiting on authentication endpoints, credential reveals, and bulk export/import

Self-hosted by design

Because Termi is self-hosted, your data — credentials, session history, server inventory — lives in your own PostgreSQL database, on infrastructure you control. There's no third-party cloud in the path, and the project ships with zero telemetry.

Reporting a vulnerability

Please do not open a public issue for a security vulnerability. Instead:

1. GitHub Security Advisories (preferred)
2. Private contact via the maintainer's GitHub profile

Full details: SECURITY.md

---

Related pages: Features · FAQ · Home