Policies

How a policy works

A policy is three things: a scope (which hosts), a mode (how firmly), and a set of rules. When you connect to a host, MangoSSH finds every enabled policy whose scope matches it, works out one value per rule, and uses that value for the connection. Bastion hops and Scripts go through the same resolution, so they get the same answer.

Each on/off rule has three choices in the editor: On, Off, or — no opinion —. Leave a rule on “no opinion” and the policy does not touch it at all, so the host's own setting (or another policy) decides.

Create a policy

1. Click Dashboard in the toolbar, then Policies in the sidebar.

2. Click ＋ New policy. The editor opens below the Global section.

3. Give it a Name people will recognise on the host form, such as “Production”.

4. Choose Applies to and, for a group or tag, which one. Then choose the Mode.

5. Under Rules this policy sets, set only the rules you care about. Under Requirements this policy checks, tick Required for any requirement.

6. Click Save policy. The policies table shows it with its mode, scope and rule chips, and a count such as “12 hosts in scope · all compliant”.

Click any row in the table to edit that policy. Delete removes it after a confirmation, and hosts return to their own settings. Creating, changing and deleting policies are written to the audit log.

Rules a policy sets

These are written onto each host in scope at connect time. Except where noted, they are the same switches you would otherwise set on the host form.

Requirements a policy checks

Two rules cannot be switched on from a policy, because each needs something only the host can provide:

• Require an MFA-capable login: the host's sign-in must prompt for a second factor. On the host's Authentication tab that means Interactive, or SSH Key with Key + Interactive Login.
• Require the PAM broker: the host must be set up through the PAM Broker wizard, which needs the password and the host key fingerprint.

So these are checked, not set. A host that falls short is non-compliant:

• The policies table shows “N non-compliant” in red next to the policy.
• Open the policy and the Compliance section lists each failing host and what it lacks, with a Fix… button that opens that host's form.
• Connecting still works. You get a warning toast first, for example “Policy Production requires MFA — this host uses password auth”, and the connection goes ahead. This holds under a mandatory policy too.

When several policies match

A host can be in scope of several policies: one for all hosts, one for its group, one for a tag. MangoSSH settles each rule separately:

1. Mandatory beats default, whatever the values are.

2. Within the same mode, the most restrictive value wins: On beats Off, the shorter certificate lifetime wins, the smaller key age wins. For the KRL path, which is a single file, the policy listed first in the table wins.

3. Then the host: if the winner is a default policy and the host has overridden that rule, the host's own value is used. A host can never override a mandatory policy.

For example, a default “All hosts” policy with recording Off and a default “Databases” tag policy with recording On leaves a database host recording. Make the “All hosts” policy mandatory and it would win instead.

What the host form shows

Open a host with Edit. Each control a policy governs shows the policy's value and a badge under it:

The governed controls are Prompt for Just-In-Time approval before connecting (Access tab), Strict mode (Advanced tab), the KRL path (Authentication tab, key sign-in only), and on the Session tab Always record sessions, Follow server sshd log, Block file transfer (SFTP) on this host and Block port forwarding on this host. The top of the Session tab also lists every policy applied to the host, mandatory first, with a Manage policies link.

Certificate lifetime, key age and the agent/X11 block have no control of their own on the host form. They still apply at connect time.

The Global section

The top of the Policies page gathers fleet-wide switches that also appear elsewhere in the app. All but the first are stored on your vault server and apply to everyone in the vault, and only a vault admin can change them.

Without a Cloud Vault or Self Hosting Vault, only the recording default is shown, with a note that the rest need a vault server.

Worked example: record every production session

Say your production hosts are in an SSH group called Production. If you mark them with a tag instead, choose A tag in step 3.

1. Open Dashboard → Policies and click ＋ New policy.

2. Name it Production recording.

3. Set Applies to to A group and pick Production.

4. Set Mode to Mandatory — locked on every host, so nobody can switch it off on one host.

5. Set Always record the session to On. Leave every other rule on — no opinion —.

6. Click Save policy. The row shows how many hosts are in scope.

7. Check one host: Edit → Session. Always record sessions is on, locked, and badged “🔒 Set by policy Production recording (mandatory)”.

8. Connect. The session is recorded from the first byte, and the recording appears under Dashboard → Session Logs.

New hosts added to the Production group are covered the moment they are saved. There is nothing to tick on each one.

Limits in this version

• Policies are stored on this device, per MangoSSH profile, and are not synced through the vault. A teammate's MangoSSH applies only the policies on their own device. The Global settings that live on the vault server are the exception.
• SSH hosts only. Policies do not apply to RDP or VNC hosts.
• Requirement rules warn, they do not refuse. A non-compliant host still connects after the warning.
• Recording and the data-copy blocks run in this app, so they bind honest use of MangoSSH, not a modified client or another tool.

Troubleshooting