Every SSH session, controlled and recorded
suSSHi is a self-hosted SSH gateway: one entry point to your data center and cloud, with policy-based access control, protocol-level inspection and full session replay. Open source, running on your own infrastructure.
Your only entry to data center
and cloud resources
Server estates keep growing — physical machines, virtual machines, cloud instances, network equipment, appliances. Keeping account and access management consistent for every administrative user on every one of those systems quickly stops being feasible.
So teams work around it: an ever-growing list of authorized keys on each host, and passwords shared between admins. Control over administrative access erodes — and with it any audit trail that would stand up to review.
Chef Cuisine
suSSHi Chef is the central user account and access management of the suSSHi Suite. A modern user interface supports you in all administrative tasks. suSSHi Chef adds advanced integrations and automation: a full REST API puts every part of the configuration under version control and CI.
One installation can serve many tenants, each with its own configuration and its own data. Service providers run all their customers from a single suSSHi Chef.
Support for multiple access control models
suSSHi is deliberately flexible about authentication and authorization: it supports Public Key Authentication, Keyboard-Interactive, and Password authentication on the client side as well as on the target side, several combinations are possible, depending on your business requirements.
suSSHi runs every authentication dialog inside the SSH authentication phase itself. It eases client error handling and allows graphical SSH clients with authentication dialogs to display them correctly instead of having authentication prompts showing up in the terminal session.
The authentication and authorization process can be extended through a plug-in architecture, either by your team or by our professional services.
SSO and OIDC login for SSH sessions
Long-lived SSH keys are hard to inventory and harder to revoke. suSSHi Sous Chef lets your identity provider decide instead. When a user opens a session, the gateway prints a one-time URL in the terminal; the user opens it, logs in through your normal corporate login — with whatever MFA, conditional access and device posture checks you already enforce — and the session continues. No new credential is issued, and nothing is provisioned on the target.
Because OIDC is configured as part of a Client Auth Set, you choose how strict to be. A set can require a public key and an OIDC login, so both must succeed before a session starts. With IP session caching enabled, a user authenticates interactively once and further sessions from the same client IP continue on the public key alone — strong verification without a browser round trip for every connection.
Sous Chef also gives users a self-service page for their own SSH public keys: they add and remove keys themselves, with no ticket and no administrator in the loop. If you would rather not expose that, it stays switched off.
Flexible user mapping
suSSHi maps real people onto shared administrative accounts such as root while keeping every action attributable to the individual who performed it. Built-in regex mapping rules let you express those mappings as patterns instead of maintaining them one entry at a time.
Flexible targets
suSSHi supports different kinds of targets to be ready for all situations. Static Targets allow the static mapping to IP addresses with pre-configured (or scanned) host keys - this is the most secure way to have targets configured.
Dynamic Targets allow the use of DNS hostnames (FQDN) to identify targets and either have host-keys pre-configured (or scanned) or dynamically learned by the gateway. All dynamically learned host-keys have to be accepted and are stored individually per user.
Domain Targets allow the use of DNS domain names to identify targets. Target host-keys are dynamically learned by the gateway which suits environments where hosts are created and destroyed constantly, such as cloud infrastructure. Network Targets act like Domain Targets but based on IPv4 or IPv6 CIDR addressed networks if you want to configure targets by network IP addresses instead of domain names.
Target fusions (Enterprise Edition) treat a target user and target host as a single tuple, so root@host1, admin@host2 and regular@host3 can sit in one rule instead of three.
Protocol deep Inspection and Logging
Each session through suSSHi gateways undergoes a deep packet inspection for all SSH messages within the SSH protocol. Specialized dissectors analyze the traffic and produce protocol-aware audit logs for every session and sub-protocol in the SSHv2 protocol suite.
You get fine-grained control over what is permitted and what is denied, and over protocol-specific logging: interactive sessions, file transfers, port forwarding, SSH agent forwarding, tunneling and more can each be allowed, blocked or logged in detail.
The suSSHi Chef Enterprise Edition even allows you to store all audit logs in an encrypted format, encrypted per administrator, using each administrator's own ED25519 key. Nobody reads a recorded session they are not entitled to — including whoever operates the gateway.
Session recording and replay
Every session through a suSSHi Gateway can be recorded in full — the output the user saw, and every keystroke they typed. Recording happens per channel, so an interactive shell, an SFTP transfer and a port forward opened inside one SSH session each leave their own trail.
The susshi-play command replays a recorded terminal session at its original speed, exactly as it happened. You can also export a recording as a ttyrec file, or as a single self-contained HTML file that an auditor opens in any browser — no suSSHi installation, no shell access, no training required.
Recording is not limited to terminals. SCP and SFTP transfers are logged file by file, so it is clear which files were touched and how. Forwarded TCP and X11 traffic is written as libpcap files that open directly in Wireshark. With the Enterprise Edition, all of it can be encrypted at rest so that only the administrators you designate can read a recording — even if the storage itself is compromised.
IPv4 and IPv6 support
suSSHi has full support for IPv4 and IPv6 and both IP versions can be mixed in various ways.
The IP protocol of the connectivity to the target server is completely independent from the IP protocol of the client connection from the client to the gateway. This for example allows users coming from an IPv4 only network to connect to servers in an IPv6 deployment and vice versa. Even port forwarding can be combined both-way.
suSSHi implements an extended form of Happy Eyeballs (RFC 6555) with administrator-configurable behavior for dual-stack environments. So you can choose from having IPv6 or IPv4 addresses preferred and suSSHi tries to connect to targets in preferred order. It even iterates through lists of IP addresses if DNS resolves to multiple IP addresses for a target.
Bastions, proxies and
dynamic OTP target authentication
Some targets cannot be reached from the gateway at all — a segmented production network, a lab with overlapping addressing, a customer environment behind NAT. suSSHi Proxy is deployed at the edge of that environment and becomes its single point of contact: the gateway connects to the proxy, and the proxy reaches the target. Users notice nothing, and the same access rules, protocol inspection and recording still apply.
The same component can run in bastion mode, serving interactive sessions on the proxy host itself — a jump host with the full suSSHi policy model in front of it. Bastion access has its own Bastion Rules and Bastion Profiles, so what someone may do on the bastion is configured separately from what they may do on the targets behind it.
Dynamic one-time passwords remove the last set of static credentials. Instead of storing a password for every device, suSSHi Chef generates a one-time password for each individual connection; the gateway presents it to the target, which verifies it against suSSHi Chef within a short validity window. Nothing reusable is stored on the gateway, and nothing reusable is stored on the device. Our manual walks through a FreeRADIUS integration — network equipment is where per-device password management hurts most.
Gateway performance and scale-out
Logging into a target system via suSSHi adds less than 100ms of delay compared to a direct login. The gateway forwards at wire rate. Users do not notice it — not at session setup, and not during the session.
All session reporting runs asynchronously, so it never blocks session I/O. Interactive sessions and file transfers see negligible added latency and jitter.
Add gateways whenever you need more parallel sessions. Each gateway operates independently and can sit in a different L3 network; suSSHi Chef can also run as multiple instances for redundancy.
Compatibility and hardening
suSSHi comes with a lot of features and protocol support to make it as compatible and flexible for modern SSH servers and clients. suSSHi supports current key types (ED25519), current ciphers (AES-256), SHA-256-based MACs and key exchange, post-quantum cryptography, compression, OpenSSH-specific behavior and extensions, and configurable idle and maximum-session timeouts.
With the integration of firewall/proxy functionality supported by common SSH GUI clients into suSSHi, users continue using their existing connection settings in their clients.
Self-hosted, your data, European vendor
suSSHi runs on your infrastructure. The gateways, suSSHi Chef and the PostgreSQL database are containers you deploy in your own data center or your own cloud account. Session recordings, audit logs, user records and access rules never leave systems you control, and there is no vendor cloud anywhere in the connection path — if our network is down, your administrators still reach their servers.
suSSHi is built and supported by Wasabi Elements GmbH in Stuttgart, Germany. You contract with a European company under German law, and the people who answer your support tickets are the people who write the software.
Open source, AGPL, free Docker images
The suSSHi Gateway, the suSSHi Chef core and suSSHi Sous Chef are open source under the AGPL-3.0-or-later. You can read the code that terminates your administrators' SSH sessions, review it, and build it yourself — a reasonable thing to require of anything sitting in front of your production estate.
Getting started does not involve a sales conversation. Pull the multi-arch images for x86-64 and ARM64, bring up a gateway, suSSHi Chef and PostgreSQL with Docker Compose, and you have a working gateway the same evening. The Personal plan costs nothing and includes every open-source feature.
The Enterprise Edition adds proxies and bastions, audit log encryption, target fusions and dynamic one-time passwords, and is licensed commercially. It ships as the same container image and activates from your subscription token — nothing to reinstall when you upgrade.
Running suSSHi in production
suSSHi Chef is where you watch the estate, not just configure it. The dashboard shows session distribution alongside current counts of access policies, gateway users, target users and targets. Session reports document every SSH session in real time — connection events, executed commands, a full timeline — and an administrator can terminate an active session directly from the interface.
System events aggregate and correlate messages from every registered gateway into one place, so you search once instead of logging into each gateway in turn. Gateways ship their system and access logs centrally, which means the audit trail leaves the gateway as it is written rather than sitting on the box being audited.
The rest is deliberately unexciting. The suSSHi Chef container has built-in backup, list and restore commands on top of whatever you already run for PostgreSQL. Containers expose Docker health checks. Every component is a multi-arch container you deploy with the tooling you already have, whether that is Docker Compose, Kubernetes or a managed platform.