It’s Time to Implement MFA for Remote Privileged Access to Linux Servers

As the share of organizations’ Linux servers, both physical and virtual, increases, many have implemented additional security controls to safeguard access to them. The best approach is to deploy a privileged access management (PAM) tool coupled with multifactor authentication (MFA), but some organizations balk at implementing PAM (too expensive!) and try to get by, implementing MFA alone. In this three-part post I’ll discuss how MFA can be added to SSH-based remote authentication to Linux:

• Part 1 covers MFA methods based on public key cryptography (PKC) and public key infrastructure (PKI).
• Part 2 (you are here) discusses modern MFA methods used across multiple used cases, including remote access to Linux.
• Part 3 covers MFA-enabled tools for remote privileged access to Linux.

Part 2: Modern MFA

Modern MFA methods can be integrated into the SSH authentication flow in the following ways:

• On MFA-aware servers, for example, OpenSSH, by configuring the first factor such as password and the second factor as ‘something else,’ for example, public keys.
• By stacking several pluggable authentication modules (I’ll use the acronym ‘p.a.m.’ to distinguish them from privileged access management [PAM] also referenced in this post).
• By implementing RADIUS-based authentication. A RADIUS server or proxy can be responsible for both authentication factors, for example, a password and a one-time password (OTP).
• By implementing a ForceCommand directive executing a mandatory command that implements either second-factor authentication or full MFA, depending on other server settings.

Figure 1 shows modern mainstream MFA methods.

Certain methods can deliver passwordless MFA on their own. For example, many MFA vendors now allow administrators to require users to authenticate locally using Touch ID or Face ID before accepting a push notification or getting the next value generated by a mobile OTP token. A couple of vendors (for example, Entrust) include proprietary biometric authentication in their mobile authenticator app.

Some MFA methods are purely in-band, some out-of-band and some use a combination of in-band and out-of-band communications. The out-of-band methods require a companion device: a smart, cell or fixed phone. Figure 2 illustrates a typical flow for mobile push-based authentication. The in-band methods may use embedded credentials, a companion device, or a dedicated device such as a hardware token.

Table 1 illustrates the different flows and devices used by modern authentication methods from Figure 1.

Table 1. Modern Authentication Methods, Flows and Devices

Vendors that support modern MFA for SSH access include: Authlogics, Broadcom-Symantec, Cisco-Duo Security, HYPR, Ping Identity, Secret Double Octopus, Thales, Twilio-Authy, WatchGuard, and many, many others. Open-source implementations are also available. See, for example, Google Authenticator, LinOTP, and privacyIDEA. If you have access to Gartner, you may want to check out Solution Comparison for Cloud MFA Services.

Additional Approaches

FIDO

I described in-band FIDO authentication for SSH as a special case of public key-based authentication in Part 1 of this post. Here I’ll touch on out-of-band (OOB) FIDO authentication that can be added to many non-web use cases (such as VPN, SSH, Remote Desktop, VDI and others) lacking FIDO support.

I am aware of two methods for OOB FIDO authentication for SSH: one is push-based, the other SMS-based where a link is sent to users’ smartphones, and they complete a FIDO handshake over a web browser channel. I will illustrate the first one below (Figure 3).

OAuth 2.0 Device Flow

The OAuth 2.0 device flow (authorization grant) was designed ‘for Internet- connected devices that either lack a browser to perform a user-agent-based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical.’ Its primary constituency are smart devices, but there have been implementations for SSH-based access as well. The most notable example is Microsoft’s Azure AD-based authentication to Linux VMs in Azure (now deprecated). In addition, Okta and Oracle (along with many others) support the OAuth 2.0 device flow in their cloud identity service and made code available (as a p.a.m.) for implementing SSH server-side functionality (see here and here).

Figure 4 explains how the device flow works.

This approach is powerful because it allows organizations to reduce SSH authentication to web authentication which typically provides more flexibility in supporting MFA and adaptive access (e.g., all common browsers support FIDO). Its main drawback is poor UX: the user must open a web browser, manually copy the code, and then ask the SSH client to continue. I think that an SSH client automatically launching a browser and completing these operations under the hood would greatly improve UX and promote wider adoption.

Summary

Commercial products and services and open-source implementations provide excellent coverage for SSH-based access using modern MFA. Gartner recommends buying MFA solutions that can be treated as ‘enterprise plumbing’: the same MFA solution should be able to address all or most enterprise use cases including access to Linux servers. A leading MFA product will plug right in using one of the integration options discussed at the beginning of this post.

However, there may be special requirements that justify implementation of another tool. I heard from some clients that they are concerned about connecting their Linux servers to the cloud (for cloud-based MFA services). Another common consideration is the fact that privileged access requires higher assurance. A typical MFA tool will support many authentication methods including those that satisfy this need, but not all allow restricting methods that can be used in this specific use case.