SSH strict "pubkey with a password" required for login?

Question

Did i misunderstand from this post?

RequiredAuthentications2 | Usually this is done to require pubkey and 2-factor authentication token, not the user's password.

you can use RequiredAuthentications2 pubkey,password to require both pubkey and password authentication. Usually this is done to require pubkey and 2-factor authentication token, not the user's password.

This mean you can login with a pubkey or with a password or do i need a pubkey with a password?

AuthenticationMethods For example, "publickey,password publickey,keyboard-interactive" would require the user to complete public key authentication, followed by either password or keyboard interactive authentication. Only methods that are next in one or more lists are offered at each stage, so for this example it would not be possible to attempt password or keyboard-interactive authentication before public key.

AuthenticationMethods "publickey,password"

AuthenticationMethods "publickey,password" "publickey,keyboard-interactive"

Is this the same like:

PubkeyAuthentication yes
PasswordAuthentication yes

For example, "publickey,publickey" requires successful authentication using two different public keys.

This is an option too "publickey,publickey"

Instead of publickey and password required

publickey and publickey(2 publickey for login)

What's with PubkeyAuthOptions

The verify-required option requires a FIDO key signature attest that the user was verified, e.g. via a PIN.

Is it possible in SSH to strict "pubkey with a password" required for login?

This means SSH can accept either password authentication or public key authentication, it's not about a "password-protected public key authentication." — ThoriumBR, Jul 15 '22 at 14:54
So this is the same AuthenticationMethods "publickey,password" "publickey,keyboard-interactive" and PubkeyAuthentication yes | PasswordAuthentication yes — Z0OM, Jul 15 '22 at 14:55
This question seems to be more about server configuration than security, I am recommending it be migrated to serverfault.se — CaffeineAddiction, Jul 15 '22 at 15:57
This is a security question not a server question | 2 auth is always sec — Z0OM, Jul 15 '22 at 15:58
The subject is security, that doesn’t mean it’s a question for SE. especially since it’s about configuration. Also the awnser is that you require 2 (or more) chains of validation to pass. So a certificate login and a password login. For example. It says nothing about how the key is stored. — LvB, Jul 16 '22 at 08:07

score 3 · Accepted Answer · edited Jul 18 '22 at 15:23

TL;DR

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.

Comparing Controls

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.

SSH strict "pubkey with a password" required for login?

1 Answers1

TL;DR

Analysis and Recommendations

Comparing Controls

See Also