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
|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.
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.
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.
The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.
Comments are closed