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 user name, 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.13, 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 user names 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.