Danger: openssh from ports config shows false security

When you install security/openssh-portable, you will get a default server config in /usr/local/etc/ssh/sshd_config, that contains this stance:

Code:
# To enable tunneled clear text passwords, change to yes here!
#PasswordAuthentication no

You don't need to so this, because they are already enabled. The stance in the config file is wrongly patched.

But otherwise, if You don't want brute-force attacks to succeed, then please uncomment this line.

(bug reported #261342)
 
It is badly worded, but it in the pkg-install message you have:
Users are encouraged to create single-purpose users with ssh keys, disable
Password authentication by setting 'PasswordAuthentication no' and
'ChallengeResponseAuthentication no', and to define very narrow sudo
privileges instead of using root for automated tasks.
I don't know why they changed the commented default value from OpenBSD, to match those of FreeBSD when there are not the correct default.
 
PasswordAuthentication (using the system's password database directly, you probably never want that nowadays) is VERY different from ChallengeResponseAuthentication (which uses PAM and could do any challenge-response style, although entering a password is the most common thing here).

No bug.
 
I just noticed the same thing while doing a new install. I was checking the config and was surprised to see I could still ssh in with a password. After uncommenting it, it functioned as I expected.
 
PasswordAuthentication (using the system's password database directly, you probably never want that nowadays)
So then why is it enabled by default?
We are not talking about challenge-response, we are talking about plain password auth.

is VERY different from ChallengeResponseAuthentication (which uses PAM and could do any challenge-response style, although entering a password is the most common thing here).

I didn't compile with PAM. I don't use PAM, and, honestly, I don't really understand PAM. I stick with the things I do understand, that is either Gssapi/Krb5 or PublicKey.

Agreed. It's actually a backdoor.
 
It is badly worded, but it in the pkg-install message you have:

Yes, you have that. You read that, you check the config file, you see that it is already set to no, and you go back to sleep.

I don't know why they changed the commented default value from OpenBSD, to match those of FreeBSD when there are not the correct default.
Probably just forgot to remove the hash mark.
I think it's a good idea to switch that off by default.

The strange thing is, there are lots of penetration tests, this should have been noticed by long.
 
Maybe there are other backends for ChallengeResponseAuthentication than PAM (but be aware PAM is part of the base system and disabling it is really asking for trouble, e.g. you'll need a privileged process to do any authentication without it).

It doesn't really matter. I just tested it. Disabling ChallengeResponseAuthentication (and leaving PasswordAuthentication commented out) disables my ability to log in using a password.

So, again: NO BUG.

And just to state the obvious: There's only one reason for "insecurity" of authentication schemes relying on passwords: insecure passwords.
 
Maybe there are other backends for ChallengeResponseAuthentication than PAM (but be aware PAM is part of the base system and disabling it is really asking for trouble, e.g. you'll need a privileged process to do any authentication without it).

What's the trouble with this:
Code:
_OPTIONS_READ=openssh-portable-8.8.p1_1,1
_FILE_COMPLETE_OPTIONS_LIST=BLACKLISTD BSM DOCS FIDO_U2F HPN KERB_GSSAPI LDNS LIBEDIT NONECIPHER PAM TCP_WRAPPERS XMSS MIT HEIMDAL HEIMDAL_BASE
OPTIONS_FILE_UNSET+=PAM
 
I don't even have ssh in base. Of course it has this option, it's the new name for the deprecated KbdInteractiveAuthentication.

You should really verify things before just claiming nonsense.
 
Yeah, this was probably wrong. I tried to download a package from FreeBSD repo, but that did apparently not work because it found one in the active deploy system instead.
 
Now I have definitely the one from FreeBSD repo, with the 'cpe' tag. There is PAM = "on".
But it has the same config as the locally compiled one, and there is no ChallengeResponseAuthentication:
# cksum sshd_config.sample /usr/local/etc/ssh/sshd_config.sample
1527641861 3215 sshd_config.sample
1527641861 3215 /usr/local/etc/ssh/sshd_config.sample

But KbdInteractiveAuthentication it has.
 
Now I installed the package as distributed.
And I can still login straightways with the user password. But now it is using "kbd-interactive" instead of "password".
And when I disable Kbd-interactive, it does not allow password method either.

So yes, now I see Your point. You are right insofar that with the default options the wrongly edited configuration of PasswordAuthentication has no serious effect because it does not get used, anyway.
But in my case, I do not want KbdInteractive any more than I would want PasswordAuthentication. I want SingleSignOn and only that.

BTW: is "kbd-interactive" in any way safer against brute-force attacks than password method?
 
But KbdInteractiveAuthentication it has.
That's "kind of" a bug, that name is deprecated, it should read ChallengeResponseAuthentication (I think it's correct in the comment directly above?)

BTW: is "kbd-interactive" in any way safer against brute-force attacks than password method?
Not if the backend just uses passwords. With PAM, other things would be possible (e.g. OTP), but passwords are the standard. Then it's pretty much the same as if OpenSSH did password authentication itself. It all depends on the quality of the passwords used.
 
But in my case, I do not want KbdInteractive any more than I would want PasswordAuthentication.
Sure. Although password authentication isn't inherently insecure, it is often insecure in practice because "weak" passwords are used much too often, so you might want to eliminate that risk.

Still, that's not a bug, it's just a default that doesn't match your preferences 🤷‍♂️

If you could indeed show the server offering the actual password mechanism without explicitly disabling it in the config, yes, that would be a bug, but I can't reproduce that here...
 
Back
Top