Passwordless Azure VM SSH login using FIDO2 security keys (Part 1)

TL;DR – Passwordless ssh to Azure VMs using FIDO2 security keys.

There are many great articles and documents on passwordless authentication, many of them are linked here. However, I wanted to focus on passwordless SSH login using FIDO2 security keys. And then I figured, why not go a little further and show this in action with some Conditional Access policies to check device compliance for good measure. That’s the topic of the posts in this series:

• Part 1 – FIDO2 and configuration (this post)
• Part 2 – Conditional Access policy to allow access only from a compliant device
• Part 3 – Passwordless SSH login in action

A super fast FIDO history recap…

The original FIDO standard is now referred to as U2F, which stands for Universal Second Factor, that is the MFA ‘flavor’ of FIDO. The new and improved (and fully passwordless) ‘flavor’ is UAF, which stands for Universal Authentication Framework, that’s FIDO2 and it uses WebAuthn and CTAP2 protocols. The most important detail is that both are based on public key cryptography and both are strongly resistant to phishing. However, FIDO2 UAF is the only passwordless protocol.

How does FIDO2 work?

It’s important to show how FIDO2 UAF works because that’s what makes it phishing resistant. However, I only highlight the most important steps below, but feel free to read more about it at the FIDO Alliance website.

The diagram above depicts the login authentication flow for FIDO2 passwordless (UAF). Prior to this point the user has already registered the security key with the relying party, that’s why the authenticator already has the private key and the relying party has the equivalent public key. The authentication flow steps are as follows:

1. User requests access to the relying party.
2. The relying party presents a challenge and its web origin.
3. The browser derives the relying party id (RP ID) from the web origin value. In the case of Azure AD, the challenge passed is a nonce (‘number once’). This prevents the token replay attacks, because it can only be used once.
4. The authenticator finds that unique pair for that specific user and that specific relying party and then prompts the user for the verification (pin or biometric). This prevents man-in-the-middle (MitM) attacks because the attacker won’t have the same web origin.
5. Once the user verifies it’s the correct human, then the authenticator uses that private key to encrypt the challenge (nonce) and sends the authenticator data back to the browser, which sends it back to the relying party.
6. The relying party then validates that the challenge was signed by the correct private key and that the nonce hasn’t been used yet and then it grants the id_token.

Note: WebAuthn is the protocol used between the browser and the relying party API, and CTAP is the protocol from the authenticator to browser.

Keep in mind the authenticator generates a unique key pair per user per relying party (web origin). So, I can use the same authenticator for two different users for the same relying party, but each has a unique key pair associated. And I can also store key pairs for different relying parties in the same authenticator. Additionally, the private key is only kept in the authenticator and it is not passed through the channels. The same goes for the PIN or biometric used to unlock the authenticator, they are not passed through the channels. This authentication process protects against phishing, man-in-the-middle, and token replay attacks.

Azure AD Setup

For this demo the only authentication method we need enabled is FIDO2 Security Key:

Although not required, it is highly recommended to restrict the specific security keys that can be registered by the users on the tenant. This is especially important for those organizations that have very specific compliance requirements. This is a fantastic security feature which unfortunately is not available with other identity providers. Some AAGUID values can be found here: Yubico, AuthnTrend. You can also find the AAGUID value from the authenticator registration information as noted here.

Please reference the Microsoft documentation for a current list of FIDO2 security keys that are known to be compatible with Azure AD UAF (passwordless).

In part 2 of this series I’ll go over the Conditional Access policy to only allow access from a compliant device.