Blog post

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

By Paul Rabinovich | March 28, 2022 | 0 Comments

Identity and Access Management and Fraud DetectionIdentity and Access Management for Technical Professionals

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.

Hardware OTP, mobile OTP, desktop OTP, SMS OTP, voice OTP. mobile push, voice callback
Figure 1. Modern Authentication Methods. Source: Gartner


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.

The application or device (directly or via a proxies, plugin, etc.) makes an API call to the authentication service. It, in turn, initiates a push message to the user's registered device and receives the outcome (accept or reject)
Figure 2. Mobile Push-Based MFA. The MFA service uses a vendor push notification network (bottom part): Apple Push Notification Service (APNS) for iOS devices or Google’s Firebase Cloud Messaging (FCM) for Android devices. Source: Cisco-Duo Security


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

Table 1. Modern Authentication Methods, Flows and Devices

Authentication Method

Description Flow

Device Type

Hardware OTP token A display, USB, NFC, Bluetooth, or Apple Lightning hardware fob to generate a sequence of one-time passwords (OTPs) unique to the device In-band Dedicated
Mobile OTP token A mobile app for OTP generation In-band Companion
Desktop OTP token A desktop app for OTP generation In-band Embedded
SMS-delivered OTP A server-generated OTP is delivered via SMS Combined Companion
Voice-delivered OTP A server-generated OTP is delivered via voice Combined Companion
Mobile push A push notification with contextual information is sent to the user’s mobile app to accept or reject Out-of-band Companion
Voice callback A voice call with contextual information is made to the user’s phone to accept or reject Out-of-band Companion


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


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

The server contacts the authentication service that sends a push notification to the user's registered smartphone. The mobile app completes a FIDO exchange through a secondary channel.
Figure 3. OOB FIDO Authentication Based on Mobile Push. Source: HYPR


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.

The server generates a unique token that the user can present to a web page to complete authentication
Figure 4. The OAuth 2.0 Device Flow. Source: Pragmatic Web Security. The SSH server is the OAuth 2.0 client in this example. One additional benefit of using OAuth 2.0 for remote access to Linux is the possibility of supporting more granular session management: the server periodically requests a new (short-lived) access token using a (long-lived) refresh token. In case of a risk event the refresh token can be revoked out-of-band and the SSH connection, terminated. I haven’t seen this implemented for SSH flows yet.


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.


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.

Note also that just implementing MFA for privileged access is not enough; MFA is only part of the solution. See Part 3 for additional information.

Comments are closed