SSH Certificate Issuance Restrictions

Issuance restrictions are the rules that define which SSH certificates a requester is allowed to request. These are set by access controls that are defined for each SSH certificate issuance template.

Use this topic to understand each of the access controls, and how to use them to create issuance restrictions for SSH certificates.

The standard access controls are described in the following table.

Access controls for client and host certificates
Control Applies to hosts? Applies to clients? Details
Allowed Principals Patterns Yes Yes One or more regex patterns used to validate the requested Principals. The request must match one or more of the regular expressions, or the connection request will be rejected.
Default Principals Yes Yes

One or more Principals that will be used if there is no Principal in the request, or if this issuance template does not allow requests to specify the desired Principal.

If left blank, and no Principal is requested, the request will be rejected.

Allowed Extensions No Yes

The certificate extensions that can be requested by the client.

For example:

permit-pty

permit-port-forwarding

login@example.com

If a non-allowed extension is requested, the request will be rejected.

Default Extensions No Yes

List of certificate extension that will be used when clients don't request extensions, or when clients are not permitted to specify extension.

Extensions are optional so you can leave this field empty.

Allowed Source Addresses No Yes

List of certificate Source Addresses that clients are allowed to request.

Source Addresses are optional so you can leave this field empty.

Default Source Addresses No Yes

You can specify certificate Source Addresses which will be used when such are not requested, or clients are not allowed to request.

Source Addresses are optional so you can leave this field empty.

Allowed Certificate Identifier (Key ID) Patterns Yes Yes

One or more regex patterns used to validate the requested certificate identifiers (Key ID).

The requested certificate identifier must be matched by at least one regular expression pattern to pass the validation.

In addition there are advanced access controls that you can set for SSH certificates, as described in the following table.

Advanced access control settings for client and host certificates
Control Applies to hosts? Applies to clients? Details
Allowed Force Command Patterns No Yes

One or more regex patterns used to validate the requested Force Command.

The requested Force Command must be matched by at least one regular expression pattern to pass the validation.

Default Force Command No Yes

You can specify Force Command which will be used when a force command is not requested, or if clients are not permitted to request a custom force command.

Force Command is optional so you can leave this field empty.

Default Certificate Identifier (Key ID) Yes Yes

You can specify certificate identifier (Key ID) which will be used when such is not requested, or clients are not allowed to request.

Certificate identifier (Key ID) is mandatory, requests will be rejected if you don’t specify default identifier or clients do not request it.

Allowed Custom Extensions No Yes

List of certificate extension that clients are allowed to request

Extensions are optional so you can leave this field empty.

Allow API clients to specify Principals Yes Yes

Whether or not API clients are allowed to specify Principals to be added to the certificate they request. When disallowed, the default principals will be used instead the one requested by clients (if any).

Even when the default principals are used, they will be validated against the allowed principal patterns.

Allow API clients to specify Extensions No Yes

Whether or not API clients are allowed to specify Extensions to be added to the certificate they request. When disallowed, the default extensions will be used instead the one requested by clients (if any).

Even when the default extensions are used, they will be validated against the allowed extensions.

Allow API clients to specify Force Command No Yes

Whether or not API clients are allowed to specify Force Command to be added to the certificate they request. When disallowed, the default Force Command will be used instead the one requested by clients (if any).

Even when the default Force Command is used, it will be validated against the allowed force command patterns.

Allow API clients to specify Source Address No Yes

Whether or not API clients are allowed to specify Source Addresses to be added to the certificate they request. When disallowed, the default Source Addresses will be used instead the one requested by clients (if any). Even when the default Source Addresses are used, they will be validated against the allowed source addresses.

Allow API clients to specify Certificate Identifier (Key ID) Yes Yes

Whether or not API clients are allowed to specify certificate identifier (Key ID) to be added to the certificate they request. When disallowed, the default certificate identifier will be used instead the one requested by clients (if any).

Even when the default certificate identifier is used, it will be validated against the allowed certificate identifier (Key ID) patterns.

Allowed Principals 'exact match' and syntax information

Since not all users are familiar with how to construct a regex, SSH Protect automatically prefixes a carrot ^ anchor and postfixes a dollar sign $ anchor whenever the content of the Allowed Principals Patterns filed doesn't already have these anchors.

For example, if you enter master-admin as the regex, SSH Protect appends the anchors, and uses ^master-admin$ for matching. In this case, it would only match master-admin exactly.

 

This is an exception to standard regex where master-admin would match the-master-admin and the-master-administrator, and master-administrator. In essence it prefixes and postfixes both the anchors described above, as well prefixing and post-fixing an unlimited-character greedy match, treating it as: ^.*master-admin.*$

Because SSH Protect treats non-prefixed and non-postfixed strings as exact match, if you want to do an unlimited-character greedy match, you will need to add the .* regex operators before and after your string. The table in the next section shows you specific examples of how this is to be done.

Regular Expression Examples

The following table illustrates some examples of how regular expressions (regex) can be used to match specific Principals. This list is not exhaustive. If you want to validate your regex, there are several sites online that can help you to ensure your expression targets the specific examples you intend.

Regular Expression matching examples
Desired Match Regex Example Matches Does Not Match
Exact Match

master-admin

^master-admin$

master-admin

the-master-admin

master-admins

masteradmin

admin

Starts-with

master-admin-.*

^master-admin-.*

master-admin-web

master-admin-SDK

master-admin-db

master-admin

the-master-admin-web

admin

Ends With

.*\.example\.com

^.*\.example\.com$

sub.example.com

www.example.com

example.com

venafi.com

All (unlimited character greedy match) .*

master-admin

sub.example.com

the-master-admin-web

any-string