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