Your browser does not allow storing cookies. We recommend enabling them.


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

Authentication chain example with nested authentication methods

Figure 5.13. Authentication chain example with nested authentication methods

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.


What to read next:

  • Reduce Secure Shell risk. Get to know the NIST 7966.

    The NISTIR 7966 guideline from the Computer Security Division of NIST is a direct call to action for organizations regardless of industry and is a mandate for the US Federal government.
    Download now
  • ISACA Practitioner Guide for SSH

    With contributions from practitioners, specialists and SSH.COM experts, the ISACA “SSH: Practitioner Considerations” guide is vital best practice from the compliance and audit community.
    Download now