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.
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
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
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.