openssh unix dev - Mar 2022 - Does a known security issue allow ssh login via system accounts?

On Tue, 03/01/22, 2022 at 09:45:04AM +1100, Damien Miller wrote:
> It sounds like you have already verified that your PAM configuration was
> not tampered with, so that removes one possibility. Reviewing the Ubuntu
> PAM configurations and the patches they apply to sshd seem to be prudent
> next steps.
Found the culprit: me. I was stupid enough to install and configure for
libpam-google-auth, given a company mandate to 2FA all connections with
admin access, where it wasn't in scope to add 2FA to all client accounts. If
there's existing documentation anywhere on how dangerous this is, it's
not
in libpam-google-auth's own docs, nor in the recipes scattered across the
net.

I've found no way yet to tweak it to be safe that I can be sure of, short of
running a separate sshd on another port for it. Has there been consideration
of adding 2FA to OpenSSH that doesn't require enabling PAM? Public keys and
IP restrictions seem enough to me. Yet my corporate overlord is required by
their insurance firm to use 2FA. To satisfy that demand, I compromised
security with the badly documented libpam-google-auth -- as if a firm that
can't even secure their flagship browser should be trusted on security.

Stupid me,

Whit

On 07/03/2022 16:14, Whit Blauvelt wrote:
> Found the culprit: me. I was stupid enough to install and configure for
> libpam-google-auth, given a company mandate to 2FA all connections with
> admin access, where it wasn't in scope to add 2FA to all client
accounts.
Could you explain a bit more what went wrong?

In order to configure 2FA (*), I do this:

PasswordAuthentication no
UsePAM yes
AuthenticationMethods publickey,keyboard-interactive:pam

The comma means sshd requires publickey *and* PAM authentication to 
complete.? I can't see how this can make it any less secure than 
publickey alone, which is why I'm wondering what went wrong in your case.

If you want to disable 2FA either for certain trusted users, or certain 
trusted source IP addresses, you can use a Match block, e.g.

Match Address 192.168.0.0/16
AuthenticationMethods publickey

On the other hand, if you're trying to enable *password* authentication 
with separate 2FA, then that's certainly much trickier to get right in 
the PAM stack.? I would go for public key or certificate auth instead, 
with 2FA on top.

Alternatively, think about doing public key auth using ecdsa-sk keys and 
a U2F token - they are very cheap. You need a fairly modern openssh at 
client and server side though.

Regards,

Brian.

(*) I'm using pam_yubico, but I believe the above should apply to any 
2FA challenge/response using PAM.

On 2022/03/07 11:14, Whit Blauvelt wrote:
> On Tue, 03/01/22, 2022 at 09:45:04AM +1100, Damien Miller wrote:
> 
> > It sounds like you have already verified that your PAM configuration
was
> > not tampered with, so that removes one possibility. Reviewing the
Ubuntu
> > PAM configurations and the patches they apply to sshd seem to be
prudent
> > next steps.
> 
> Found the culprit: me. I was stupid enough to install and configure for
> libpam-google-auth, given a company mandate to 2FA all connections with
> admin access, where it wasn't in scope to add 2FA to all client
accounts. If
> there's existing documentation anywhere on how dangerous this is,
it's not
> in libpam-google-auth's own docs, nor in the recipes scattered across
the
> net.
> 
> I've found no way yet to tweak it to be safe that I can be sure of,
short of
> running a separate sshd on another port for it. Has there been
consideration
> of adding 2FA to OpenSSH that doesn't require enabling PAM? Public keys
and
Already possible:

AuthenticationMethods "publickey,password"

Depending on what you are allowed to use as a second factor and what
clients you use, the key allowed by "publickey" could be a key from a
traditional id_XXX file, or it could be a key handle for a U2F token.

On 3/7/22 17:14, Whit Blauvelt wrote:
> Found the culprit: me. I was stupid enough to install and configure for
> libpam-google-auth, given a company mandate to 2FA all connections with
> admin access,
libpam-google-auth and other similar PAM modules require to store the 
token's shared secrets on the server. If your system gets hacked and 
shared secrets are stolen the attacker can generate an arbitrary amount 
of valid OTP values. And if you use the same shared secrets on multiple 
servers the security impact will be broad.

=> Don't use that.
> Has there been consideration
> of adding 2FA to OpenSSH that doesn't require enabling PAM? Public keys
and
> IP restrictions seem enough to me.
Use the new FIDO key type.

Or use short-term OpenSSH user certificates issued by a secured SSH-CA 
which uses 2FA for user authc.

Ciao, Michael.

On Mon, 7 Mar 2022, Whit Blauvelt wrote:
> On Tue, 03/01/22, 2022 at 09:45:04AM +1100, Damien Miller wrote:
> 
> > It sounds like you have already verified that your PAM configuration
was
> > not tampered with, so that removes one possibility. Reviewing the
Ubuntu
> > PAM configurations and the patches they apply to sshd seem to be
prudent
> > next steps.
> 
> Found the culprit: me. I was stupid enough to install and configure for
> libpam-google-auth, given a company mandate to 2FA all connections with
> admin access, where it wasn't in scope to add 2FA to all client
accounts. If
> there's existing documentation anywhere on how dangerous this is,
it's not
> in libpam-google-auth's own docs, nor in the recipes scattered across
the
> net.
(off-list)

If you're able to share details of what went wrong, then please let me
know and I'll make sure they get back to the developers of this module.

-d