Your best bet is really to create a policy that enforces the use of encrypted private keys or multi-factor approaches such as 2FA or OpenPGP cards. How you enforce the policy is up to you, but there are endpoint solutions and detective scripts you could write to periodically validate that passwordless client keys are not stored in an accessible way.
Multi-factor authentication (MFA) and other identity or source restrictions configured on the server side are also valid options, and avoid a lot of the complications and downsides of key escrow while still increasing the overall security posture. Ultimately, you have to determine your actual threat model, and consider which of the many potential controls best address the organizational, administrative, and user concerns that will be associated with any risk-reduction measures you might use.
You should also consider the security trade-offs inherent in any control you decide on. All controls require trade-offs in architectural and system security, as well as convenience and usability. Controls around SSH are no different in that regard.
Analysis and Recommendations
Is it possible in SSH to strict "pubkey with a password" required for login?
If you mean can you require both a public key and a server-side password, yes.
The SSH server has no way to determine whether a client's private key has been locally encrypted on the client side with a password or not; that information isn't part of the client/server key exchange protocol. While it is certainly possible to write a privileged script to scan private keys locally to see if they're encrypted or not as part of a post facto detective control, there is currently no mechanism in OpenSSH to prevent keys from being generated as passwordless keys in the first place.
That's why multi-factor authentication and other server-side configuration controls are useful. There is no scenario under which the server can determine whether the key material presented was from a private key encrypted on disk, stored on an OpenPGP card, or otherwise protected on the client side.
If your threat model considers unencrypted private keys a risk, you should either implement client-side detective controls, multi-factor authentication, or some form of key escrow such as:
- OpenPGP-compatible cards or hard tokens (I personally like using pre-configured YubiKey tokens for this, but there are other options and your mileage may vary) where the user cannot disable passwords on the device;
- OpenSSH certificates signed by a trusted certificate authority, along with an AuthorizedPrinciplesFile;
- proxied client keys using tools such as CyberArk's Privileged Session Manager for SSH that authenticates the user but never exposes the proxied private keys directly to either clients or servers;
or use various other server-side controls that limit who can present a given SSH key or certificate using server-specific features. For example, with OpenSSH you might look at:
- sshd_config Match blocks to restrict source IP addresses;
- stacking additional PAM modules with
UsePAM yes while ensuring that public key authentication by itself is not sufficient;
- adding FIDO as an additional MFA mechanism using the OpenSSH PubKeyAuthOptions setting, with or without touch required; or
- other client factors and server-side restrictions.
Note that most of these measures require additional infrastructure (such as a certificate authority system, hardware security module, additional software systems, or other administrative overhead) and administrative management, and may create other risks because key escrow itself can create vulnerabilities and potential breach targets.
Escrow solutions are often preventative controls, but come with all the security caveats of key escrow and key management. They also require the clients to trust the party performing the key escrow, and this can create problems for non-repudiation. On the other hand, most of the client-side solutions you might implement are detective controls, and are thus not suitable for use with untrusted clients, untrusted users, or environments where monitoring must be continuous.
That's why MFA is really the low-hanging fruit here. By combining something the user has (e.g. a presumatively-private SSH key) with something else such as a password, TOTP token, one-time password (e.g. S/Key, OPIE, OTPW, port knocking, or similar), you make it harder for simple possession of an unencrypted private key to be the sole means of access to a protected system.
- Books and articles
- "Configuring One-Time Password Authentication with OTPW". Jacobs, Todd A. Linux Journal, Issue 225. (January 2013, pp. 76–88).
- PAM Mastery (IT Mastery). Lucas, Michael W. Tilted Windmill Press, September 2016.
- SSH Mastery: OpenSSH, PuTTY, Tunnels and Keys (IT Mastery Book 12). Lucas, Michael W. Tilted Windmill Press; 2nd edition (February 6, 2018).
- SSH, The Secure Shell: The Definitive Guide: The Definitive Guide Second Edition. Barret, Daniel J. et al. O'Reilly Media; 2nd edition (May 10, 2005).
- Port-knocking tools and articles