Your browser does not support HTML5 local storage or you have disabled it. Some functionality on this site, including saving your privacy settings and offering you special discounts, uses local storage and may not work with local storage disabled. We recommend allowing the use of local storage in your browser. In some browsers, it is the same setting used for disabling cookies.

SSH Tectia

Authentication Chain Example

The previous example showed how the server may be configured to select one authentication block from a list of multiple blocks using selectors. This allows the administrator to select a list of allowed authentication methods according to username, originating IP address, and various other attributes.

However, this does not allow the administrator to require more than one authentication method. The way to do this is by creating a chain of nested authentication blocks.

Authentication chain example with nested authentication methods

Figure 5.4. Authentication chain example with nested authentication methods

In the example shown in Figure 5.4, the top-level block (marked with 1) contains one method definition, hostbased. When starting the authentication exchange with the user, the server sends only that method as allowed to the client. If the user fails that method, the whole authentication fails. If the user passes the method, the server looks for a nested block (marked with 2), forms a list of methods defined in that block and sends that list to the client. In this example, the nested block contains the publickey method.

After the user has passed public-key authentication, the server looks for further blocks for a continuation. In this example, there is one nested block at the innermost level (3). The block is selected only if the user is trying to log in as root. In that case, one more authentication method is required.

If the user does not match to a nested authentication block, the action of the parent authentication element is used (in this example, allow in step 2). Users logging in with other usernames than root will be allowed in after having passed both hostbased and publickey earlier.

In step 2, the allow action is shown for clarity. The allow attribute can also be omitted from the configuration as it is the default action.

This example contains only one method at each level and results in one method being required at a time. It would also be possible to have multiple method definitions at each level, in which case passing any one of the methods would allow the authentication to proceed to the next level.