Access rulesets are structured to be searched from top to bottom based on the input parameters of a new session, consisting of source, gateway user, target user and target, with the first match being evaluated as the best match. The selected profile of this match is then applied to the connection with all its settings. Further session details are defined in the profile.
But first let’s take a look at the screenshot, which can already answer some questions:
The meaning of the individual fields is explained below:
- Max Session Time
The maximum time a session can run, regardless of whether it is actively used. After this time, the session is severely interrupted and the user logs out, even if he is managing something important on the target server. Leave empty for unlimited session time.
- Max Idle Time
The maximum time a session can remain unused. If the user does not make any input or the server does not send any output within this period, the session is severely interrupted and the user logs out. Leave empty for unlimited idle time.
- Pref. Authentication
This parameter specifies how the suSSHi Gateway attempts to authenticate itself to the target.
- Partition default
Authentication is performed using the methods and order specified for the partition under Partition Settings (default here is Public Key - Gateway Identities, Keyboard Interactive, Password).
- Public Key
The gateway attempts to log in at the destination using one of the user-provided SSH keys (Auth Agent Forwarding). Please refer to Authentication Options for more details.
- Public Key - Gateway Identities
The gateway tries to log in at the destination using one of its own gateway keys. At the destination, at least one of the gateway keys is stored in the authorised keys for the respective target user. The user key is not stored on the destination.
- Keyboard Interactive
The gateway attempts to log on to the destination using keyboard interactive authentication. This requires interaction with the user, who enters the target credentials when prompted, which are then passed to the destination by the gateway.
This method is quite similar to the Keyboard-Interactive method, only that the password method is used instead of the keyboard interactive authentication towards the target. Please refer to Authentication Options for more details.
- Target Password Source
If the target requests a password (Password or Keyboard-Interactive method), this setting controls the behaviour:
- User Dialog
The password request is forwarded to the user. This is the default.
- Preserve Password
An attempt is made to log on to the target system with the same password that was used for gateway authentication. This only works if the user authenticates with keyboard-interactive or password at the gateway.
- Static Password
A password can be stored in the profile used on the target without being displayed to the user. It is recommended to enable the target user overwrite option as well.
- Dynamic One-Time Password
For each target authentication, an individual one-time password is generated and send to the target, which can then be verified by an API call within the configured validity period.
- Target Hostkey Learning
This parameter defines what should happen in the case of a hostkey of the destination that is unknown to the gateway so far. You can set when and how the hostkey is to be learned.
Hostkey learning is done individually for each gateway user and is thus relevant only for sessions of the user who accepted the host key. This is like a personal, server-side implemented
The hostkey must not be learned or updated under any circumstances.
- Automatically: If unknown
The hostkey is to be learned automatically if the hostkey of the target is not yet known.
- Automatically: If unknown and if changes
The hostkey should be learned automatically if the hostkey of the target is not known or has changed.
- Prompt User for new and changed keys
The user is prompted whether to learn a new hostkey or to overwrite an existing one with a changed hostkey.
This parameter determines which rights are granted to the session. These switches refer to a simple rights control within the SSH protocol:
- Interactive Session
An interactive (shell) session is allowed.
- Secure Copy (SCP)
Secure Copy Protocol (SCP) is allowed.
- Secure File Transfer (SFTP)
Secure File Transfer Protocol (SFTP subsystem) is allowed.
- Auth Agent Forwarding
The SSH session allows access to the user’s auth agent. This is only required if the user is allowed to connect from the target server to another target server, which in turn authenticates using a public key.
- X11 Forwarding
Forwarding X11 connections is allowed.
- Allow subsequent SSH session within TCP forwardings
If this switch is deactivated, suSSHi prevents further SSH sessions via forwarded TCP ports.
- Logging mask
This parameter determines how detailed the recording of the session should be.
Control which subsystems (besides SFTP, which is controlled via a permission switch) are allowed.
Format: exact naming of subsystems, no regex matching!
SFTP is controlled by Secure File Transfer Protocol switch.
- Local Forwards
Control which local port forwards (
-Lin OpenSSH) are allowed in the corresponding SSH session to which this profile is applied.
[IPv6]:Port or Hostname:Port.
Asterisk (*) is supported for host and port.
localhostcan be used as shorthand for three rules matching
- Remote Forwards
Control which Remote Port Forwards (
-Rin OpenSSH) are allowed in the corresponding SSH session, this profile is applied to.
Asterisk (*) is supported for host and port. Please specify
localhostfor regular remote port forwarding requests, e.g.
-R 8000:localhost:80. If the user specifies a bind address other than localhost, use the bind address as the host part, e.g.
- Command Execs
Control which command is allowed to be executed on target server when in a non-interactive session (i.e. OpenSSH ssh <target> <command>). Format: Perl compatible regular expressions (PCRE), SCP is controlled by secure copy protocol switch.