# Danger: openssh from ports config shows false security



## PMc (Jan 19, 2022)

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


```
# 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)


----------



## monwarez (Jan 19, 2022)

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.


----------



## zirias@ (Jan 19, 2022)

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.


----------



## thinman (Jan 19, 2022)

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.


----------



## PMc (Jan 19, 2022)

Zirias said:


> 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.



Zirias said:


> No bug.


Agreed. It's actually a backdoor.


----------



## PMc (Jan 19, 2022)

monwarez said:


> 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.



monwarez said:


> 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.


----------



## zirias@ (Jan 20, 2022)

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.


----------



## PMc (Jan 20, 2022)

Zirias said:


> 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:

```
_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
```


----------



## zirias@ (Jan 20, 2022)

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.


----------



## PMc (Jan 20, 2022)

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.


----------



## PMc (Jan 20, 2022)

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.


----------



## PMc (Jan 20, 2022)

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?


----------



## zirias@ (Jan 20, 2022)

PMc said:


> 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?)



PMc said:


> 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.


----------



## zirias@ (Jan 20, 2022)

PMc said:


> 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...


----------

