the-bastion/etc/bastion/bastion.conf.dist

###############################################################################
## Main config for The Bastion.
## This is a JSON file, its syntax must be valid at all times. To verify:
## > grep -v ^# /etc/bastion/bastion.conf|python -mjson.tool>/dev/null && echo OK
##
## If you're on a production bastion you can verify it can properly load its configuration:
## > perl -I/opt/bastion/lib/perl -MOVH::Bastion -e 'OVH::Bastion::load_configuration(test=>1)'
##
#@ .. note::
#@
#@   The Bastion has a lot of configuration options so that you can tailor it
#@   to your needs. However, if you're just beggining and would like to get
#@   started quickly, just configure the ``Main Options``.
#@   All the other options have sane defaults that can still be customized
#@   at a later time.
###############################################################################
{
################
# > Main Options
# >> Those are the options you should customize when first setting up a bastion. All the other options have sane defaults and can be customized later if needed.
#
# bastionName (string)
#    DESC: This will be the name advertised in the aliases admins will give to bastion users, and also in the banner of the plugins output. You can see it as a friendly name everybody will use to refer to this machine: something more friendly than just its full hostname.
# DEFAULT: "fix-my-config-please-missing-bastion-name"
"bastionName": "fix-my-config-please-missing-bastion-name",
#
# bastionCommand (string)
#    DESC: The ``ssh`` command to launch to connect to this bastion as a user. This will be printed on ``accountCreate``, so that the new user knows how to connect. Magic tokens are:
#
#          - ACCOUNT or USER: replaced at runtime by the account name
#          - BASTIONNAME: replaced at runtime by the name defined in ``bastionName``
#          - HOSTNAME: replaced at runtime by the hostname of the system
#
#          So, for example if your specify ``ssh USER@HOSTNAME -t --``, it'll give ``johndoe@bastion1.example.org -t --`` as a bastion alias to *johndoe*
# DEFAULT: "ssh USER@HOSTNAME -t --"
"bastionCommand": "ssh USER@HOSTNAME -t -- ",
#
# readOnlySlaveMode (boolean)
#     DESC: If set to ``false``, this bastion will work in standalone mode, or will be the master in a master/slave mode. If set to ``true``, this'll be the slave which means all plugins that modify groups, accounts, or access rights will be disabled, and the master bastion will push its modifications using inotify/rsync, please refer do the documentation to set this up.
#  DEFAULT: false
"readOnlySlaveMode": false,
#
# adminAccounts (array of strings (account names))
#     DESC: The list of accounts that are Admins of the bastion. Admins can't be deleted or otherwise modified by non-admins. They also gain access to special dangerous/sensitive ``--osh`` commands, such as being able to impersonate anybody else. Note that an Admin is also always considered as a Super Owner, which means they also override all checks of group administrative commands. Don't forget to add them to the ``osh-admin`` group too (system-wise), or they won't really be considered as Admins: this is an additional security measure against privilege escalation. Rule of thumb: it's probably a good idea to only add here people that have ``root`` access to the bastion machine itself.
#  DEFAULT: []
"adminAccounts": [],
#
# superOwnerAccounts (array of strings (account names))
#     DESC: The list of accounts that are "Super Owners". They can run all group administrative commands, exactly as if they were implicitly owners of all the groups. Super Owners are only here as a last resort when the owners/gatekeepers/aclkeepers of a group are not available. Every command run by a Super Owner that would have failed if the account was not a Super Owner is logged explicitly as "Super Owner Override", you might want to add a rule for those in your SIEM. You can consider than the Super Owners have an implicit *sudo* for group management. Don't add here accounts that are bastion Admins, as they already inherit the Super Owner role. Don't forget to add them to the ``osh-superowner`` group too (system-wise), or they won't really be considered as "Super Owners": this is an additional security measure against privilege escalation.
#  DEFAULT: []
"superOwnerAccounts": [],
#
################
# > SSH Policies
# >> All the options related to the SSH configuration and policies, both for ingress and egress connections.
#
# allowedIngressSshAlgorithms (array of strings (algorithm names))
#     DESC: The algorithms authorized for ingress ssh public keys added to this bastion. Possible values: ``dsa``, ``rsa``, ``ecdsa``, ``ed25519``, note that some of those might not be supported by your current version of ``OpenSSH``: unsupported algorithms are automatically omitted at runtime.
#  DEFAULT: [ "rsa", "ecdsa", "ed25519" ]
"allowedIngressSshAlgorithms": [ "rsa", "ecdsa", "ed25519", "ecdsa-sk", "ed25519-sk" ],
#
# allowedEgressSshAlgorithms (array of strings (algorithm names))
#     DESC: The algorithms authorized for egress ssh public keys generated on this bastion. Possible values: ``dsa``, ``rsa``, ``ecdsa``, ``ed25519``, note that some of those might not be supported by your current version of ``OpenSSH``, unsupported algorithms are automatically omitted at runtime.
#  DEFAULT: [ "rsa", "ecdsa", "ed25519" ]
"allowedEgressSshAlgorithms": [ "rsa", "ecdsa", "ed25519" ],
#
# minimumIngressRsaKeySize (int > 0)
#     DESC: The minimum allowed size for ingress RSA keys (user->bastion). Sane values range from 2048 to 4096.
#  DEFAULT: 2048
"minimumIngressRsaKeySize": 2048,
#
# maximumIngressRsaKeySize (int > 0)
#     DESC: The maximum allowed size for ingress RSA keys (user->bastion). Too big values (>8192) are extremely CPU intensive and don't really add that much security.
#  DEFAULT: 8192
"maximumIngressRsaKeySize": 8192,
#
# minimumEgressRsaKeySize (int > 0)
#     DESC: The minimum allowed size for egress RSA keys (bastion->server). Sane values range from 2048 to 4096.
#  DEFAULT: 2048
"minimumEgressRsaKeySize": 2048,
#
# maximumEgressRsaKeySize (int > 0)
#     DESC: The maximum allowed size for ingress RSA keys (bastion->server). Too big values (>8192) are extremely CPU intensive and don't really add that much security.
#  DEFAULT: 8192
"maximumEgressRsaKeySize": 8192,
#
# defaultAccountEgressKeyAlgorithm (string)
#    DESC: The default algorithm to use to create the egress key of a newly created account
# DEFAULT: "rsa"
"defaultAccountEgressKeyAlgorithm": "rsa",
#
# defaultAccountEgressKeySize (int > 0)
#    DESC: The default size to use to create the egress key of a newly created account (also see ``defaultAccountEgressKeyAlgorithm``)
# DEFAULT: 4096
"defaultAccountEgressKeySize": 4096,
#
# moshAllowed (boolean)
#     DESC: If set to ``true``, mosh usage is allowed (mosh needs to be installed on serverside, obviously). Otherwise, this feature is disabled.
#  DEFAULT: false
"moshAllowed": false,
#
# moshTimeoutNetwork (int > 0)
#     DESC: Number of seconds of inactivity (network-wise) after a mosh-server will exit. By design even if the client is disconnected "for good", mosh-server would wait forever. If mosh is meant to handle shaky connections but not mobility, you can set this to a low value. It sets the ``MOSH_SERVER_NETWORK_TMOUT`` envvar for mosh, see ``man mosh-server`` for more information (mosh 1.2.6+).
#  DEFAULT: 86400
"moshTimeoutNetwork": 86400,
#
# moshTimeoutSignal (int > 0)
#     DESC: Number of seconds of inactivity (network-wise) a mosh-server will wait after receiving a ``SIGUSR1`` before exiting. It sets the ``MOSH_SERVER_SIGNAL_TMOUT`` envvar for mosh, see ``man mosh-server`` for more information (mosh 1.2.6+).
#  DEFAULT: 30
"moshTimeoutSignal": 30,
#
# moshCommandLine (string)
#     DESC: Additional parameters that will be passed as-is to mosh-server. See ``man mosh-server``, you should at least add the ``-p`` option to specify a fixed number of ports (easier for firewall configuration).
#  DEFAULT: ""
#  EXAMPLE: "-s -p 40000:49999"
"moshCommandLine": "",
#
###########################
# > Global network policies
# >> Those options can set a few global network policies to be applied bastion-wide.
#
# dnsSupportLevel (integer between 0 and 2)
#      DESC: If set to 0, The Bastion will never attempt to do DNS or reverse-DNS resolutions, and return an error if you request connection to a hostname instead of an IP. Use this if you know there's no working DNS in your environment and only use IPs everywhere.
#            If set to 1, The Bastion will not attempt to do DNS or reverse-DNS resolutions unless you force it to (i.e. by requesting connection to a hostname instead of an IP). You may use this if for example you have well-known hostnames in /etc/hosts, but don't have a working DNS (which would imply that reverse-DNS resolutions will always fail).
#            If set to 2, The Bastion will make the assumption that you have a working DNS setup, and will do DNS and reverse-DNS resolutions normally.
#   DEFAULT: 2
"dnsSupportLevel": 2,
#
# allowedNetworks (array of strings (IPs and/or prefixes))
#     DESC: Restricts egress connection attempts to those listed networks only. This is enforced at all times and can NOT be overridden by users. If you are lucky enough to have you own IP blocks, it's probably a good idea to list them here. An empty array means no restriction is applied.
#  DEFAULT: []
#  EXAMPLE: ["10.42.0.0/16","192.168.111.0/24","203.0.113.42"]
"allowedNetworks": [],
#
# forbiddenNetworks (array of strings (IPs and/or prefixes))
#     DESC: Prevents egress connection to the listed networks, this takes precedence over ``allowedNetworks``. This can be used to prevent connection to some hosts or subnets in a broadly allowed prefix. This is enforced at all times and can NOT be overridden by users.
#  DEFAULT: []
#  EXAMPLE: ["10.42.42.0/24"]
"forbiddenNetworks": [],
#
# ingressToEgressRules (array of rules, a rule being a 3-uple of [array, array, string])
#     DESC: Fine-grained rules (a la *netfilter*) to apply global restrictions to possible egress destinations given ingress IPs. This is similar to ``allowedNetworks`` and ``forbiddenNetworks``, but way more powerful (in fact, those two previous options can be expressed exclusively using ``ingressToEgressRules``). Those rules here are enforced at all times and can **NOT** be overridden by users or admins.
#           Each rule will be processed **IN ORDER**. The first rule to match will be applied and no other rule will be checked.
#           If no rule matches, the default is to apply no restriction.
#           A rule is a 3-uple of [``array of ingress networks``, ``array of egress networks``, ``policy to apply``].
#
#           - ``array of ingress networks``: if the IP of the ingress connection matches a network or IP in this list, the rule *may* apply: we proceed to check the egress network IP
#           - ``array of egress networks``: if the IP of the egress connection matches a network or IP in this list, the rule *does* apply and we'll enforce the policy defined in the third item of the rule
#           - ``policy to apply``: this is what to enforce when the ingress and egress network match
#
#           The "policy to apply" item can have 3 values:
#
#           - ``ALLOW``, no restriction will be applied (all rights-check of groups and personal accesses still apply)
#           - ``DENY``, access will be denied regardless of any group or personal accesses
#           - ``ALLOW-EXCLUSIVE``, access will be allowed **if and only if** the egress network match, given the ingress network. In other words, if the ingress IP matches one of the ingress networks specified in the rule, but the egress IP **DOES NOT** match any of the egress network specified, access will be denied. This is an easy way to ensure that a given list of ingress networks can only access a precise list of egress networks and nothing else.
#
#           For example, take the following configuration:
#
# ::
#
#              [
#                 [["10.19.0.0/16","10.15.15.0/24"], ["10.20.0.0/16"],    "ALLOW-EXCLUSIVE"],
#                 [["192.168.42.0/24"],              ["192.168.42.0/24"], "ALLOW"],
#                 [["192.168.0.0/16"],               ["192.168.0.0/16"],  "DENY"]
#              ]
#
#           - The ``10.19.0.0/16`` and ``10.15.15.0/24`` networks can only access the ``10.20.0.0/16`` network (rule ``#1``)
#           - The ``192.168.42.0/24`` network can access any machine from its own /24 network (rule ``#2``), but not any other machine from the wider ``192.168.0.0/16`` network (rule ``#3``). It can however access any other machine outside of this block (implicit allow catch-all rule, as there is no corresponding ``DENY`` rule, and rule ``#2`` is ``ALLOW`` and not ``ALLOW-EXCLUSIVE``)
#           - The ``192.168.0.0/16`` network (except ``192.168.42.0/16``) can access any machine except one from its own network (rule ``#3``)
#           - All the other networks can access any other network (including egress ``10.20.0.0/16`` or egress ``192.168.0.0/16``)
#
#          In any case, all the personal and group accesses still apply in addition to these global rules.
#  DEFAULT: []
"ingressToEgressRules": [],
#
###########
# > Logging
# >> Options to customize how logs should be produced.
#
# enableSyslog (boolean)
#     DESC: If enabled, we'll send logs through syslog, don't forget to setup your syslog daemon!. You can also adjust ``syslogFacility`` and ``syslogDescription`` below, to match your syslog configuration. Note that the provided ``syslog-ng`` templates work with the default values left as-is.
#  DEFAULT: true
"enableSyslog": true,
#
# syslogFacility (string)
#     DESC: Sets the facility that will be used for syslog.
#  DEFAULT: "local7"
"syslogFacility": "local7",
#
# syslogDescription (string)
#     DESC: Sets the description that will be used for syslog.
#  DEFAULT: "bastion"
"syslogDescription": "bastion",
#
# enableGlobalAccessLog (boolean)
#     DESC: If enabled, all *open* and *close* logs will be written to ``/home/logkeeper/global-log-YYYYMM.log``. Those are also logged through syslog if *enableSyslog* is set.
#  DEFAULT: true
"enableGlobalAccessLog": true,
#
# enableAccountAccessLog (boolean)
#     DESC: If enabled, all *open* and *close* logs will be written to the corresponding user's home in ``/home/USER/USER-log-YYYYMM.log``. Those are also logged through syslog if *enableSyslog* is set.
#  DEFAULT: true
"enableAccountAccessLog": true,
#
# enableGlobalSqlLog (boolean)
#     DESC: If enabled, all access logs (corresponding to the *open* and *close* events) will be written in a short SQL format, as one row per access, to ``/home/logkeeper/global-log-YYYYMM.sqlite``.
#  DEFAULT: true
"enableGlobalSqlLog": true,
#
# enableAccountSqlLog (boolean)
#     DESC: If enabled, all access logs (corresponding to the *open* and *close* events) will be written in a detailed SQL format, as one row per access, in the corresponding user's home to ``/home/USER/USER-log-YYYYMM.sqlite``. If you want to use ``selfListSessions`` and/or ``selfPlaySession``, this is required.
#  DEFAULT: true
"enableAccountSqlLog": true,
#
# ttyrecFilenameFormat (string)
#    DESC: Sets the filename format of the output files of ttyrec for a given session. Magic tokens are: ``&bastionname``, ``&uniqid``, ``&account``, ``&ip``, ``&port``, ``&user`` (they'll be replaced by the corresponding values of the current session). Then, this string (automatically prepended with the correct folder) will be passed to ttyrec's ``-F`` parameter, which uses ``strftime()`` to expand it, so the usual character conversions will be done (``%Y`` for the year, ``%H`` for the hour, etc., see ``man strftime``). Note that in a addition to the usual ``strftime()`` conversion specifications, ttyrec also supports ``#usec#``, to be replaced by the current microsecond value of the time.
# DEFAULT: "%Y-%m-%d.%H-%M-%S.#usec#.&uniqid.&account.&user.&ip.&port.ttyrec"
"ttyrecFilenameFormat": "%Y-%m-%d.%H-%M-%S.#usec#.&uniqid.&account.&user.&ip.&port.ttyrec",
#
# ttyrecAdditionalParameters (array of strings)
#    DESC: Additional parameters you want to pass to ``ttyrec`` invocation. Useful, for example, to enable on-the-fly compression, disable cheatcodes, or set/unset any other ``ttyrec`` option. This is an ARRAY, not a string.
# EXAMPLE: ["-s", "This is a message with spaces", "--zstd"]
# DEFAULT: []
"ttyrecAdditionalParameters": [],
#
# ttyrecStealthStdoutPattern (regex)
#
#  DESC: When this is set to a non-falsy value, this is expected to be a string that will be converted to a regex which will be matched against a potential remote command specified when connecting through SSH to a remote server. If the regex matches, then we'll instruct ttyrec to NOT record stdout for this session.
# EXAMPLE: "^rsync --server .+"
# DEFAULT: ""
"ttyrecStealthStdoutPattern": "",
#
##########################
# > Other ingress policies
# >> Policies applying to the ingress connections
#
# ingressKeysFrom (array of strings (list of IPs and/or prefixes))
#    DESC: This array of IPs (or prefixes, such as ``10.20.30.0/24``) will be used to build the ``from="..."`` in front of the ingress account public keys used to connect to the bastion (in ``accountCreate`` or ``selfAddIngressKey``). If the array is empty, then **NO** ``from="..."`` is added (this lowers the security).
# DEFAULT: []
"ingressKeysFrom": [],
#
# ingressKeysFromAllowOverride (boolean)
#    DESC: If set to ``false``, any user-specified ``from="..."`` prefix on keys in commands such as ``selfAddIngressKey`` or ``accountCreate`` are silently ignored and replaced by the IPs in the ``ingressKeysFrom`` configuration option (if any).
#          If set to ``true``, any user-specified ``from="..."`` will override the value set in ``ingressKeysFrom`` (if any).
#          Note that when no user-specified ``from="..."`` appears, the value of ``ingressKeysFrom`` is still used, regardless of this option.
# DEFAULT: false
"ingressKeysFromAllowOverride": false,
#
#########################
# > Other egress policies
# >> Policies applying to the egress connections
#
# defaultLogin (string)
#      DESC: The default remote user to use for egress ssh connections where no user has been specified by our caller. If set to the empty string (``""``), will default to the account name of the caller. If your bastion is mainly used to connect as ``root`` on remote systems, you might want to set this to ``root`` for example, to spare a few keystrokes to your users. This is only used when no user is specified on the connection line. For example if your bastion alias is ``bssh``, and you say ``bssh srv1.example.net``, the value of the ``defaultLogin`` value will be used as the user to login as remotely.
#   DEFAULT: ""
"defaultLogin": "",
#
# egressKeysFrom (array of strings (IPs and/or prefixes))
#     DESC: These IPs will be added to the ``from="..."`` of the personal account keys and the group keys. Typically you want to specify only the bastions IP here (including all the slaves). Note that if this option is NOT set at all or set to the empty array, it will default to autodetection at runtime (using ``hostname --all-ip-addresses`` under the hood). This is dependent from your system configuration and is therefore discouraged.
#  DEFAULT: []
"egressKeysFrom": [],
#
# keyboardInteractiveAllowed (boolean)
#     DESC: If set to ``true``, will allow keyboard-interactive authentication when publickey auth is requested for egress connections, this is needed e.g. for 2FA.
#  DEFAULT: true
"keyboardInteractiveAllowed": true,
#
# passwordAllowed (boolean)
#     DESC: If set to ``true``, will allow password authentication for egress ssh, so that user can type his remote password interactively.
#  DEFAULT: false
"passwordAllowed": false,
#
# telnetAllowed (boolean)
#     DESC: If set to ``true``, will allow telnet egress connections (``-e`` / ``--telnet``).
#  DEFAULT: false
"telnetAllowed": false,
#
####################
# > Session policies
# >> Options to customize the established sessions behaviour
#
# displayLastLogin (boolean)
#     DESC: If ``true``, display their last login information on connection to your users.
#  DEFAULT: true
"displayLastLogin": true,
#
# fanciness (string)
#     DESC: Customize to which extent the text output by the program will use decorations to enhance human-friendliness and highlight warnings or critical messages. Note that if a given session's terminal doesn't advertise UTF-8 support, UTF-8 will not be used, regardless of what is set here.
#
#           - "none": Text will only consist of us-ascii characters
#           - "basic": UTF-8 characters will be used to draw tables, instead of ---'s, among other things
#           - "full": Some emoticons may appear to highlight important messages
#  DEFAULT: full
"fanciness": "full",
#
# interactiveModeAllowed (boolean)
#     DESC: If set to ``true``, ``--interactive`` mode is allowed. Otherwise, this feature is disabled.
#  DEFAULT: true
"interactiveModeAllowed": true,
#
# interactiveModeTimeout (int >= 0 (seconds))
#     DESC: The number of idle seconds after which the user is disconnected from the bastion when in interactive mode. A value of 0 will disable this feature (user will never be disconnected for idle timeout).
#  DEFAULT: 60
"interactiveModeTimeout": 60,
#
# interactiveModeByDefault (boolean)
#     DESC: If ``true``, drops the user to interactive mode if nothing is specified on the command line. If ``false``, displays the help and exits with an error. Note that for ``true`` to have the expected effect, interactive mode must be enabled (see the ``interactiveModeAllowed`` option above).
#  DEFAULT: true
"interactiveModeByDefault": true,
#
# interactiveModeProactiveMFAenabled (boolean)
#     DESC: If enabled, the ``mfa`` command is allowed in interactive mode, to trigger a proactive MFA challenge, so that subsequent commands normally requiring MFA won't ask for it again.
#  DEFAULT: true
"interactiveModeProactiveMFAenabled": true,
#
# interactiveModeProactiveMFAexpiration (int >= 0 (seconds))
#     DESC: If the above ``interactiveModeProactiveMFAenabled`` option is ``true``, then this is the amount of seconds after which the proactive MFA mode is automatically disengaged.
#  DEFAULT: 900
"interactiveModeProactiveMFAexpiration": 900,
#
# idleLockTimeout (int >= 0 (seconds))
#     DESC: If set to a positive value >0, the number of seconds of input idle time after which the session is locked. If ``false``, disabled.
#  DEFAULT: 0
"idleLockTimeout": 0,
#
# idleKillTimeout (int >= 0 (seconds))
#     DESC: If set to a positive value >0, the number of seconds of input idle time after which the session is killed. If ``false``, disabled. If ``idleLockTimeout`` is set, this value must be higher (obviously).
#  DEFAULT: 0
"idleKillTimeout": 0,
#
# warnBeforeLockSeconds (int >= 0 (seconds))
#     DESC: If set to a positive value >0, the number of seconds before ``idleLockTimeout`` where the user will receive a warning message telling them about the upcoming lock of his session. Don't enable this (by setting a non-zero value) if `idleLockTimeout` is disabled (set to zero).
#  DEFAULT: 0
"warnBeforeLockSeconds": 0,
#
# warnBeforeKillSeconds (int >= 0 (seconds))
#     DESC: If set to a positive value >0, the number of seconds before ``idleKillTimeout`` where the user will receive a warning message telling them about the upcoming kill of his session. Don't enable this (by setting a non-zero value) if `idleKillTimeout` is disabled (set to zero).
#  DEFAULT: 0
"warnBeforeKillSeconds": 0,
#
# accountExternalValidationProgram (string (path to a binary))
#    DESC: Binary or script that will be called by the bastion, with the account name in parameter, to check whether this account should be allowed to connect to the bastion. If empty, this check is skipped. ``$BASEDIR`` is a magic token that is replaced by where the bastion code lives (usually, ``/opt/bastion``).
#
#          You can use this configuration parameter to counter-verify all accounts against an external system, for example an *LDAP*, an *Active Directory*, or any system having a list of identities, right when they're connecting to the bastion (on the ingress side). However, it is advised to avoid calling an external system in the flow of an incoming connection, as this violates the "the bastion must be working at all times, regardless of the status of the other components of the company's infrastructure" rule. Instead, you should have a cronjob to periodically fetch all the allowed accounts from said external system, and store this list somewhere on the bastion, then write a simple script that will be called by the bastion to verify whether the connecting account is present on this locally cached list.
#
#          An account present in this list is called an *active account*, in the bastion's jargon. An *inactive* account is an account existing on the bastion, but not in this list, and won't be able to connect. Note that for security reasons, inactive bastions administrators would be denied as any other account.
#
#          The result is interpreted from the program's exit code. If the program return 0, the account is deemed active. If the program returns 1, the account is deemed inactive. A return code of 2, 3 or 4 indicates a failure of the program in determining the activeness of the account. In this case, the decision to allow or deny the access is determined by the ``accountExternalValidationDenyOnFailure`` option below. Status code 3 additionally logs the ``stderr`` of the program *silently* to the syslog: this can be used to warn admins of a problem without leaking information to the user. Status code 4 does the same, but the ``stderr`` is also shown directly to the user. Any other return code deems the account inactive (same behavior that return code 1).
# DEFAULT: ""
# EXAMPLE: "$BASEDIR/bin/other/check-active-account-simple.pl"
"accountExternalValidationProgram": "",
#
# accountExternalValidationDenyOnFailure (boolean)
#    DESC: If we can't validate an account using the program configured in ``accountExternalValidationProgram``, for example because the path doesn't exist, the file is not executable, or because the program returns the exit code 4 (see above for more information), this configuration option indicates whether we should deny or allow access.
#
#          Note that the bastion admins will always be allowed if the ``accountExternalValidationProgram`` doesn't work correctly, because they're expected to be able to fix it. They would be denied, as any other account, if ``accountExternalValidationProgram`` works correctly and denies them access, however. If you're still testing your account validation procedure, and don't want to break your users workflow while you're not 100% sure it works correctly, you can say ``false`` here, and return 4 instead of 1 in your ``accountExternalValidationProgram`` when you would want to deny access.
# DEFAULT: true
"accountExternalValidationDenyOnFailure": true,
#
# alwaysActiveAccounts (array of strings (account names))
#    DESC: List of accounts which should NOT be checked against the ``accountExternalValidationProgram`` mechanism above (for example bot accounts). This can also be set per-account at account creation time or later with the ``accountModify`` plugin's ``--always-active`` flag.
# DEFAULT: []
"alwaysActiveAccounts": [],
#
####################
# > Account policies
# >> Policies applying to the bastion accounts themselves
#
# accountMaxInactiveDays (int >= 0 (days))
#     DESC: If > 0, deny access to accounts that didn't log in since at least that many days. A value of 0 means that this functionality is disabled (we will never deny access for inactivity reasons).
#  DEFAULT: 0
"accountMaxInactiveDays": 0,
#
# accountExpiredMessage (string)
#     DESC: If non-empty, customizes the message that will be printed to a user attempting to connect with an expired account (see ``accountMaxInactiveDays`` above). When empty, defaults to the standard message "Sorry, but your account has expired (#DAYS# days), access denied by policy.". The special token ``#DAYS#`` is replaced by the number of days since we've last seen this user.
#  DEFAULT: ""
"accountExpiredMessage": "",
#
# accountCreateSupplementaryGroups (array of strings (system group names))
#     DESC: List of system groups to add a new account to when its created (see ``accountCreate``). Can be useful to grant some restricted commands by default to new accounts. For example ``osh-selfAddPersonalAccess``, ``osh-selfDelPersonalAccess``, etc. Note that the group here are **NOT** *bastion groups*, but system groups.
#  DEFAULT: []
"accountCreateSupplementaryGroups": [],
#
# accountCreateDefaultPersonalAccesses (array of strings (list of IPs and/or prefixes))
#     DESC: List of strings of the form USER@IP or USER@IP:PORT or IP or IP:PORT, with IP being IP or prefix (such as 1.2.3.0/24). This is the list of accesses to add to the personal access list of newly created accounts. The special value ACCOUNT is replaced by the name of the account being created. This can be useful to grant some accesses by default to new accounts (for example ACCOUNT@0.0.0.0/0)
#  DEFAULT: []
"accountCreateDefaultPersonalAccesses": [],
#
# ingressRequirePIV (boolean), since: v3.01.99-rc1
#     DESC: When set to true, only PIV-enabled SSH keys will be able to be added with selfAddIngressKey, hence ensuring that an SSH key generated on a computer, and not within a PIV-compatible hardware token, can't be used to access The Bastion. If you only want to enable this on a per-account basis, leave this to false and set the flag on said accounts using accountPIV instead. When set to false, will not require PIV-enabled SSH keys to be added by selfAddIngressKey. If you have no idea what PIV keys are, leave this to false, this is what you want.
#  DEFAULT: false
"ingressRequirePIV": false,
#
# accountMFAPolicy (string)
#     DESC: Set a MFA policy for the bastion accounts, the supported values are:
#
#     - ``disabled``: the commands to setup TOTP and UNIX account password are disabled, nobody can setup MFA for themselves or others. Already configured MFA still applies, unless the sshd configuration is modified to no longer call PAM on the authentication phase
#     - ``password-required``: for all accounts, a UNIX account password is required in addition to the ingress SSH public key. On first connection with his SSH key, the user is forced to setup a password for his account, and can't disable it afterwards
#     - ``totp-required``: for all accounts, a TOTP is required in addition to the ingress SSH public key. On first connection with his SSH key, the user is forced to setup a TOTP for his account, and can't disable it afterwards
#     - ``any-required``: for all accounts, either a TOTP or an UNIX account password is required in addition to the ingress SSH public key. On first connection with his SSH key, the user is forced to setup either of those, as he sees fit, and can't disable it afterwards
#     - ``enabled``: for all accounts, TOTP and UNIX account password are available as opt-in features as the users see fit. Some accounts can be forced to setup either TOTP or password-based MFA if they're flagged accordingly (with the accountModify command)
#
#  DEFAULT: "enabled"
"accountMFAPolicy": "enabled",
#
# MFAPasswordMinDays (int >= 0 (days))
#    DESC: For the PAM UNIX password MFA, sets the min amount of days between two password changes (see ``chage -m``)
# DEFAULT: 0
"MFAPasswordMinDays": 0,
#
# MFAPasswordMaxDays (int >= 0 (days))
#    DESC: For the PAM UNIX password MFA, sets the max amount of days after which the password must be changed (see ``chage -M``)
# DEFAULT: 90
"MFAPasswordMaxDays": 90,
#
# MFAPasswordWarnDays (int >= 0 (days))
#    DESC: For the PAM UNIX password MFA, sets the number of days before expiration on which the user will be warned to change his password (see ``chage -W``)
# DEFAULT: 15
"MFAPasswordWarnDays": 15,
#
# MFAPasswordInactiveDays (int >= -1 (days))
#    DESC: For the PAM UNIX password MFA, the account will be blocked after the password is expired (and not renewed) for this amount of days (see ``chage -E``). -1 disables this feature. Note that this is different from the ``accountMaxInactiveDays`` option above, that is handled by the bastion software itself instead of PAM
# DEFAULT: -1
"MFAPasswordInactiveDays": -1,
#
# MFAPostCommand (array of strings (a valid system command))
#    DESC: When using JIT MFA (i.e. not directly by calling PAM from SSHD's configuration, but using ``pamtester`` from within the code), execute this command on success.
#          This can be used for example if you're using ``pam_tally2`` or ``pam_faillock`` in your PAM MFA configuration, ``pamtester`` can't reset the counter to zero because this is usually done in the ``account_mgmt`` PAM phase. You can use a script to reset it here.
#          The magic token ``%ACCOUNT%`` will be replaced by the account name.
#          Note that usually, ``pam_tally2`` can only be used by root (hence might require the proper sudoers configuration), while ``faillock`` can directly be used by unprivileged users to reset their counter.
# DEFAULT: []
# EXAMPLE: ["sudo","-n","-u","root","--","/sbin/pam_tally2","-u","%ACCOUNT%","-r"] or ["/usr/sbin/faillock","--reset"]
"MFAPostCommand": [],
#
# TOTPProvider (string)
#    DESC: Defines which is the provider of the TOTP MFA, that will be used for the ``(self|account)MFA(Setup|Reset)TOTP`` commands. Allowed values are:
#          - none: no TOTP providers are defined, the corresponding setup commands won't be available.
#          - google-authenticator: the pam_google_authenticator.so module will be used, along with its corresponding setup binary. This is the default, for backward compatibility reasons. This is also what is configured in the provided pam templates.
#          - duo: enable the use of the Duo PAM module (pam_duo.so), of course you need to set it up correctly in your `/etc/pam.d/sshd` file.
# DEFAULT: 'google-authenticator'
"TOTPProvider": "google-authenticator",
#
#################
# > Other options
# >> These options are either discouraged (in which case this is explained in the description) or rarely need to be modified.
#
# accountUidMin (int >= 100)
#     DESC: Minimum allowed UID for accounts on this bastion. Hardcoded > 100 even if configured for less.
#  DEFAULT: 2000
"accountUidMin": 2000,
#
# accountUidMax (int > 0)
#     DESC: Maximum allowed UID for accounts on this bastion.
#  DEFAULT: 99999
"accountUidMax": 99999,
#
# ttyrecGroupIdOffset (int > 0)
#     DESC: Offset to apply on user group uid to create its ``-tty`` group, should be > ``accountUidMax - accountUidMin`` to ensure there is no overlap.
#  DEFAULT: 100000
"ttyrecGroupIdOffset": 100000,
#
# documentationURL (string)
#     DESC: The URL of the documentation where users will be pointed to, for example when displaying help. If you have some internal documentation about the bastion, you might want to advertise it here.
#  DEFAULT: "https://ovh.github.io/the-bastion/"
"documentationURL": "https://ovh.github.io/the-bastion/",
#
# debug (boolean)
#     DESC: Enables or disables debug *GLOBALLY*, printing a lot of information to anyone using the bastion. Don't enable this unless you're chasing a bug in the code and are familiar with it.
#  DEFAULT: false
"debug": false,
#
# remoteCommandEscapeByDefault (boolean)
#     DESC: If set to ``false``, will not escape simple quotes in remote commands by default. Don't enable this, this is to keep compatibility with an ancient broken behavior. Will be removed in the future. Can be overridden at runtime with ``--never-escape`` and ``--always-escape``.
#  DEFAULT: false
"remoteCommandEscapeByDefault": false,
#
# sshClientDebugLevel (int (0-3))
#     DESC: Indicates the number of ``-v``'s that will be added to the ssh client command line when starting a session. Probably a bad idea unless you want to annoy your users.
#  DEFAULT: 0
"sshClientDebugLevel": 0,
#
# sshClientHasOptionE (boolean)
#     DESC: Set to ``true`` if your ssh client supports the ``-E`` option and you want to use it to log debug info on opened sessions. **Discouraged** because it has some annoying side effects (some ssh errors then go silent from the user perspective).
#  DEFAULT: false
"sshClientHasOptionE": false
}