Hello, even the very first remote hole for OpenBSD, back in 2002 was about that the:
https://web.archive.org/web/20160915002152/http://www.iss.net/threats/advise123.html https://www.cvedetails.com/cve/CVE-2002-0639/ "ChallengeResponseAuthentication" was set to yes.. (it was more, but it would be mitigated with setting to "NO") So I think ChallengeResponseAuthentication should be set to NO, since it is not used by anything by default (you need manual steps as root to use ex.: skey). But please, correct me, I just want to point out an attack surface reduction in OpenSSH + OpenBSD. Many thanks. > Sent: Sunday, December 29, 2019 at 6:07 PM > From: "lu hu" <luhu8...@mail.com> > To: misc@openbsd.org > Subject: Re: Why isn't ChallengeResponseAuthentication NO in sshd_config? > > Hello: > > 66# grep -i challenge /etc/ssh/sshd_config > #ChallengeResponseAuthentication yes > 66# sshd -T|grep -i challenge > challengeresponseauthentication yes > 66# > > it doesn't counts if it is commented out, since it is by default YES as I > started the thread with: > > > > #################### > > > # what am I talking about? > > > > > > https://man.openbsd.org/sshd_config#ChallengeResponseAuthentication > > > > > > ChallengeResponseAuthentication > > > Specifies whether challenge-response authentication is allowed. All > > > authentication styles from login.conf(5) are supported. The default is > > > yes. > > > > anyone in this world that understands what am I trying to point out? :) > > with all the infos so far I have, the "ChallengeResponseAuthentication" > should be by default NO. but it isn't currently. > > maybe someone from the devs? or sorry, am I posting to the wrong list? > > Really Many Thanks. > > Happy New Year! > > > > > Sent: Monday, December 23, 2019 at 1:58 PM > > From: "Jan Betlach" <jbetl...@gmail.com> > > To: "lu hu" <luhu8...@mail.com> > > Cc: misc@openbsd.org > > Subject: Re: Why isn't ChallengeResponseAuthentication NO in sshd_config? > > > > > > Isn’t it commented out by default? > > > > Jan > > > > > > > Hello, > > > > > > nobody about the $subject? :) > > > > > > Why isn't ChallengeResponseAuthentication NO in sshd_config by > > > default? > > > > > > It would be more secure, afaik. > > > > > > Many thanks. > > > > > > > > >> Sent: Thursday, December 19, 2019 at 7:58 PM > > >> From: "lu hu" <luhu8...@mail.com> > > >> To: misc@openbsd.org > > >> Subject: Re: Why isn't ChallengeResponseAuthentication NO in > > >> sshd_config? > > >> > > >>> Sent: Wednesday, December 18, 2019 at 9:49 PM > > >>> From: "Bodie" <bo...@bodie.cz> > > >>> To: misc@openbsd.org, owner-m...@openbsd.org > > >>> Subject: Re: Why isn't ChallengeResponseAuthentication NO in > > >>> sshd_config? > > >>> > > >>> > > >>> > > >>> On 18.12.2019 18:48, lu hu wrote: > > >>>> Hello, > > >>>> > > >>>> #################### > > >>>> # what am I talking about? > > >>>> > > >>>> https://man.openbsd.org/sshd_config#ChallengeResponseAuthentication > > >>>> > > >>>> ChallengeResponseAuthentication > > >>>> Specifies whether challenge-response authentication is allowed. > > >>>> All > > >>>> authentication styles from login.conf(5) are supported. The default > > >>>> is > > >>>> yes. > > >>>> > > >>>> #################### > > >>>> # what does linux distros use: > > >>>> > > >>>> If I ex.: read: > > >>>> > > >>>> https://access.redhat.com/solutions/336773 > > >>>> > > >>>> then I can see ChallengeResponseAuthentication is NO for security > > >>>> reasons. Ubuntu too. > > >>>> > > >>>> #################### > > >>>> # what else says ChallengeResponseAuthentication should be NO? > > >>>> > > >>>> https://www.openwall.com/lists/oss-security/2019/12/04/5 > > >>>> -> > > >>> > > >>> These issues were quickly fixed in OpenBSD as you can see in > > >>> Security > > >>> > > >> > > >> This isn't related to the subject. > > >> > > >>> > > >>>> 1. CVE-2019-19521: Authentication bypass > > >>>> > > >>>> this attack should be more mitigated if > > >>>> ChallengeResponseAuthentication would be by default set to NO. > > >>>> > > >>>> #################### > > >>>> # FIX: > > >>>> > > >>>> from this: > > >>>> cat /etc/ssh/sshd_config > > >>>> ... > > >>>> # Change to no to disable s/key passwords > > >>>> #ChallengeResponseAuthentication yes > > >>>> ... > > >>>> > > >>>> to this: > > >>>> vi /etc/ssh/sshd_config > > >>>> cat /etc/ssh/sshd_config > > >>>> ... > > >>>> # Change to no to disable s/key passwords > > >>>> ChallengeResponseAuthentication no > > >>>> ... > > >>>> > > >>>> But of course by default, without fixing sshd_config it should be > > >>>> NO. > > >>>> > > >>>> Who the hell uses s/key with sshd nowadays? > > >>>> > > >>> > > >>> And you are aware that this option is not there just for S/Key, > > >>> right? > > >>> It's for example PAM Google authenticator too on Linux and > > >>> others.... > > >>> > > >>> I think you missed couple of points. Eg.: > > >>> > > >>> https://www.openbsd.org/faq/faq10.html#SKey > > >>> > > >>> and the fact that login.conf(5) on OpenBSD by default enables S/Key. > > >>> > > >> > > >> I checked the https://www.openbsd.org/faq/faq10.html#SKey > > >> > > >> first step is to have a /etc/skey dir. So checked it: > > >> > > >> 66# ls /etc/skey > > >> ls: /etc/skey: No such file or directory > > >> 66# > > >> > > >> There is no /etc/skey by default. So you have to do the "skeyinit -E" > > >> as root, etc. Same for Google authenticator, etc. So > > >> ChallengeResponseAuthentication should be only enabled then.. when > > >> you set up extra auth methods. > > >> > > >> So afaik skey isn't enabled by default on OpenBSD, but for still some > > >> unkown reason (for me) ChallengeResponseAuthentication is set to yes > > >> by default on OpenBSD. > > >> > > >> Why? > > >> > > >>>> #################### > > >>>> > > >>>> So please, can we make the default sshd_config more secure and set > > >>>> the > > >>>> "ChallengeResponseAuthentication to NO"? > > >>>> > > >>> > > >>> Some practical examples at hand of the current vulnerability which > > >>> will > > >>> make this change reasonable? > > >> > > >> It is about proactive security, to avoid future possible security > > >> issues. > > >> > > >>> > > >>>> Many thanks and whishing a peaceful xmas! > > >>> > > >>> > > >> > > >> > > > > > >
