EN
Contact sales

Server Gateway

Records who did what on your servers, by name

The gateway terminates SSH on both sides to decide who logs in to which server with which account, controls the commands run and the files transferred, and records the session screen. Users keep using ssh and sftp as usual.

  • SSH
  • SFTP
  • TCP portsComing soon

What is Server Gateway?

Server Gateway is a server access control gateway that sits in the path people take to reach servers over SSH. It takes over the job of a bastion host (jump server) and also records who connected and what they did.

BeeHind terminates SSH on both sides. The gateway accepts the user's SSH connection and makes its own separate connection to the target server. That lets it read and decide on commands, file transfers and port forwarding inside encrypted SSH. Nothing is installed on target servers.

It uses the same user list, the same policy screens and the same audit store as DAC and AI Gateway.

Login

Choose a login method for each server account

When the gateway logs in on the user's behalf (credential injection), users do not need to know the server's password or SSH key. Whether to accept a login is always up to the target server.

MethodWhat the user doesWhat the gateway doesSetup on the target server
User inputEnters the server account's passwordPasses what was entered to the target server as is, without storing itNothing
Stored passwordNothingLogs in on the user's behalf with a stored passwordNothing
Stored SSH keyNothingLogs in on the user's behalf with a stored SSH keyAdd the public key to authorized_keys for each account
CertificateNothingCreates a short-lived certificate for each connection and logs in on the user's behalfOnce per server, configure it to trust the cluster's user CA

The way into servers is the desktop agent's tunnel. No separate port is opened for server access, and users run ssh with the real server address and server account.

Blocked commands and file transfers show the reason on the spot

Commands that the command template does not allow are not passed to the server. The connection stays open, and only the reason is shown. The reason messages below are exactly what the product sends.

ssh deploy@web-01.internal
deploy@web-01:~$ tail -n 1 /var/log/app/error.log2026-11-09 10:42:17 WARN payment timeout (order 1024)deploy@web-01:~$ rm -rf /var/www/releases[BeeHind] Command template 'Prod read-only': this command is not allowed (rm -rf /var/www/releases)sftp> put customers.csvUploading customers.csv to /home/deploy/customers.csv[BeeHind] Command template 'Prod read-only': this file function is not allowed (upload)remote open("/home/deploy/customers.csv"): Permission denied

Recording session · Commands and file transfers are recorded under kim.dev@corp

Control

Decisions from connection to command and file

Policies are set per user and group in the admin console. Connections without a matching rule are rejected.

  • Access rules

    Allow or deny connections for each combination of user or group, server and server account. You can also set the IP ranges and hours allowed to connect.

  • Command control

    Use command templates to define the commands to block or allow. Both commands run as ssh server command and commands typed into an interactive shell are checked.

  • Commands that need approval

    Commands needed only during maintenance, such as service restarts or sudo, are blocked normally and can run only while a command permission is approved.

  • File control

    Reads SFTP and lets through only the operations you allow among upload, download and file changes. scp and rsync are checked by the same rules, and each transferred file is recorded in the audit log.

  • Port forwarding

    Forwarding opened with ssh -L or ssh -D goes only to the destinations (host and port) allowed for each user. It is off by default, and reverse forwarding (ssh -R) is rejected.

  • Session recording

    Records the session screen for playback in the admin console. Keystrokes typed by the user are not stored, so passwords never end up in recordings.

  • Session management

    Force open sessions to close. Revoking an access rule closes its open sessions too, and you can set an idle timeout and a maximum session length.

  • Host key verification

    The target server's host key is pinned when the server is registered and checked on every connection. The agent registers the cluster's host CA on the PC, so users are never asked to confirm a fingerprint.

Supported scope

As of October 2026

Connection path
Tunnel from the desktop agent (macOS, Windows)
Tested tools
OpenSSH ssh, sftp, scp, rsync
Login methods
User input, stored password, stored SSH key, certificate
File transfer
SFTP (version 3), scp, rsync
Audit
Connections, commands, file transfers, port forwarding, session recordings
Recording store
S3-compatible storage
TCP ports (coming soon)
We are preparing per-user access to server ports that do not go through SSH (for example web admin consoles, Redis and RDP), with a record of each connection. The gateway does not interpret the content of these connections.

Known limitations

  • Commands typed into an interactive shell are checked by reading the line drawn on screen. Unlike commands run as ssh server command, this is an estimate.
  • Block-list command templates alone cannot stop files from moving in and out through the shell.
  • The content of forwarded connections is not inspected. SQL sent to a database over a forwarded connection is not recorded in the audit log, so register databases as DAC services.
  • Secrets shown on screen remain in the recording as is.
  • Agentless connections, web terminals, RDP, Telnet and FTP are not supported yet.

See BeeHind in your own environment

Tell us which databases, servers and AI services you need to protect and how your network is laid out. We will recommend a setup and a rollout order. You can start with a single server.

Contact salesFAQ