3 ms·

That's because most two-factor authentication methods rely on keyboard-interactive auth to prompt the user. After using a different auth method (such as public

That's because most two-factor authentication methods rely on keyboard-interactive auth to prompt the user. After using a different auth method (such as public-key), the SSH daemon then presents the need for additional authentication, with keyboard-interactive as the available option. This works by specifying `keyboard-interactive:pam` as the authentication method, and modifying SSH's PAM stack to call whatever PAM module handles the second factor. Notably, any PAM module which asks for a password (for example, "pam_unix") is removed from SSH's PAM stack.

tialaramex 5y ago
If you can, you should do this via FIDO Security Keys instead. You do need a modern SSH (client and server) and of course money to buy keys for whoever is authenticated, but for employee systems in particular that's a very small expenditure and is re-usable for other problems (e.g. web site authentication with WebAuthn). With Security Keys you can get a physical device you've decided you trust to authenticate that its authorised user is present remotely. Although the keys aren't very bright, they do understand a handful of bitflags they're signing, and two of those bitflags are "User Present" and "User Verified", by requiring "User Verified" the physical device you trust must have verified the authorised user (e.g. local PIN, fingerprint sensor) before signing the message. This approach is more robust, because it's all happening in the SSH public key authentication layer, not in ad-hoc PAM code, and it's simpler because there is no "second factor" data living on your SSH servers, the second factor is a problem for the authenticator only, yet it also re-uses an authenticator your employees can use to e.g. authenticate to your local gitlab install, or your Google docs, or even to decrypt their laptops on startup.

tialaramex 5y ago

If you can, you should do this via FIDO Security Keys instead. You do need a modern SSH (client and server) and of course money to buy keys for whoever is authenticated, but for employee systems in particular that's a very small expenditure and is re-usable for other problems (e.g. web site authentication with WebAuthn). With Security Keys you can get a physical device you've decided you trust to authenticate that its authorised user is present remotely. Although the keys aren't very bright, they do understand a handful of bitflags they're signing, and two of those bitflags are "User Present" and "User Verified", by requiring "User Verified" the physical device you trust must have verified the authorised user (e.g. local PIN, fingerprint sensor) before signing the message. This approach is more robust, because it's all happening in the SSH public key authentication layer, not in ad-hoc PAM code, and it's simpler because there is no "second factor" data living on your SSH servers, the second factor is a problem for the authenticator only, yet it also re-uses an authenticator your employees can use to e.g. authenticate to your local gitlab install, or your Google docs, or even to decrypt their laptops on startup.