Fw: Re: openiked.org down?
Hello? https://www.openiked.org/ is still down. Thanks. > Sent: Tuesday, January 07, 2020 at 8:27 PM > From: "lu hu" > To: direct...@openbsdfoundation.org > Subject: Fw: Re: openiked.org down? > > Hello, > > can you please help to bring back > > https://www.openiked.org/ > > to life? someone even updated the wiki page to > https://en.wikipedia.org/wiki/OpenIKED > > > > Sent: Sunday, January 05, 2020 at 3:10 PM > > From: "lu hu" > > To: misc@openbsd.org, t...@openbsd.org > > Subject: Re: openiked.org down? > > > > who can bring up openiked.org to life? > > > > > Sent: Tuesday, December 31, 2019 at 4:14 PM > > > From: "Umgeher Torgersen" > > > To: misc@openbsd.org > > > Subject: Re: openiked.org down? > > > > > > yeah, it's down... > > > > > > ; <<>> DiG 9.4.2-P2 <<>> openiked.org > > > ;; global options: printcmd > > > ;; Got answer: > > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58691 > > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > > > > > > ;; QUESTION SECTION: > > > ;openiked.org. IN A > > > > > > ;; AUTHORITY SECTION: > > > openiked.org. 2496IN SOA > > > a.ns.bsws.de. noc.bsws.de. 1577745128 1 3600 604800 86400 > > > > > > ;; Query time: 0 msec > > > ;; SERVER: 10.0.5.5#53(10.0.5.5) > > > ;; WHEN: Tue Dec 31 15:14:22 2019 > > > ;; MSG SIZE rcvd: 82 > > > > > > On Tue, Dec 31, 2019 at 03:08:47PM +0100, lu hu wrote: > > > > Hello, > > > > > > > > did anyone noticed that the https://openiked.org/ is down? > > > > > > > > NO "A" record is associated with the domain? > > > > > > > > Thanks for any infos. > > > > > > > > > > > > > >
Re: Why isn't ChallengeResponseAuthentication NO in sshd_config?
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" > 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" > > To: "lu hu" > > 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" > > >> 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" > > >>> 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 > > >>> > > >>
possible SSH algorithm issues?
Hello, used https://www.sshaudit.com/ + ssh-audit package ### by default OpenBSD 6.6 ssh client (SSH-2.0-OpenSSH_8.1) has issues: Host Key Types: nistp should be removed Key Exchange Algorithms: nistp should be removed, also diffie-hellman-group14-sha1: SHA-1 has exploitable weaknesses. Message Authentication Codes: umac-64-...@openssh.com MAC uses small tag size. + hmac-sha1-...@openssh.com SHA-1 has exploitable weaknesses. + umac...@openssh.com MAC uses small tag size. + hmac-sha1 SHA-1 has exploitable weaknesses. ### by default OpenBSD 6.6 sshd server (SSH-2.0-OpenSSH_8.1) has issues: # key exchange algorithms (kex) ecdh-sha2-nistp256-- [fail] using weak elliptic curves (kex) ecdh-sha2-nistp384-- [fail] using weak elliptic curves (kex) ecdh-sha2-nistp521-- [fail] using weak elliptic curves # host-key algorithms (key) ecdsa-sha2-nistp256 -- [fail] using weak elliptic curves ### are these real issues? nistp + weak macs. that are advised to be removed by ssh-audit? Googled misc archives, didn't found any discussion about these! (yet) Many thanks.
Fw: Re: sshd_config#PermitRootLogin typo
fuck I did a typo, sorry, I wanted to write: 66# sshd -T|grep -i permitr permitrootlogin without-password 66# really sorry. But the issue is still there. man page says there should be prohibit-password and not without-password > Sent: Sunday, January 05, 2020 at 3:07 PM > From: "lu hu" > To: misc@openbsd.org > Subject: Re: sshd_config#PermitRootLogin typo > > yes! > > > Sent: Sunday, January 05, 2020 at 3:00 PM > > From: "Robert Klein" > > To: misc@openbsd.org > > Subject: Re: sshd_config#PermitRootLogin typo > > > > On Sun, 5 Jan 2020 14:47:15 +0100 > > "lu hu" wrote: > > > > > Hello, > > > > > > http://man.openbsd.org/sshd_config#PermitRootLogin > > > says > > > ...The default is prohibit-password. > > > If this option is set to prohibit-password (or its deprecated alias, > > > without-password), password and keyboard-interactive authentication > > > are disabled for root. > > > > > > SO: > > > > > > if I remove the PermitRootLogin line from sshd_config, then rcctl > > > restart sshd, then why can I see > > > > > > 66# sshd -T|grep -i permitr > > > permitrootlogin yes > > > 66# > > > > > > instead of prohibit-password ? > > > > > > Thanks! > > > > > > > Was the deleted one the only “PermitRootLogin” line in your > > /etc/ssh/sshd_config? > > > >
Re: openiked.org down?
who can bring up openiked.org to life? > Sent: Tuesday, December 31, 2019 at 4:14 PM > From: "Umgeher Torgersen" > To: misc@openbsd.org > Subject: Re: openiked.org down? > > yeah, it's down... > > ; <<>> DiG 9.4.2-P2 <<>> openiked.org > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58691 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;openiked.org. IN A > > ;; AUTHORITY SECTION: > openiked.org. 2496IN SOA > a.ns.bsws.de. noc.bsws.de. 1577745128 1 3600 604800 86400 > > ;; Query time: 0 msec > ;; SERVER: 10.0.5.5#53(10.0.5.5) > ;; WHEN: Tue Dec 31 15:14:22 2019 > ;; MSG SIZE rcvd: 82 > > On Tue, Dec 31, 2019 at 03:08:47PM +0100, lu hu wrote: > > Hello, > > > > did anyone noticed that the https://openiked.org/ is down? > > > > NO "A" record is associated with the domain? > > > > Thanks for any infos. > > > >
Fw: Re: Why isn't ChallengeResponseAuthentication NO in sshd_config?
Hello, any thoughts anyone? > Sent: Sunday, December 29, 2019 at 6:07 PM > From: "lu hu" > 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" > > To: "lu hu" > > 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" > > >> 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" > > >>> 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 > > >>
Re: sshd_config#PermitRootLogin typo
yes! > Sent: Sunday, January 05, 2020 at 3:00 PM > From: "Robert Klein" > To: misc@openbsd.org > Subject: Re: sshd_config#PermitRootLogin typo > > On Sun, 5 Jan 2020 14:47:15 +0100 > "lu hu" wrote: > > > Hello, > > > > http://man.openbsd.org/sshd_config#PermitRootLogin > > says > > ...The default is prohibit-password. > > If this option is set to prohibit-password (or its deprecated alias, > > without-password), password and keyboard-interactive authentication > > are disabled for root. > > > > SO: > > > > if I remove the PermitRootLogin line from sshd_config, then rcctl > > restart sshd, then why can I see > > > > 66# sshd -T|grep -i permitr > > permitrootlogin yes > > 66# > > > > instead of prohibit-password ? > > > > Thanks! > > > > Was the deleted one the only “PermitRootLogin” line in your > /etc/ssh/sshd_config? > >
sshd_config#PermitRootLogin typo
Hello, http://man.openbsd.org/sshd_config#PermitRootLogin says ...The default is prohibit-password. If this option is set to prohibit-password (or its deprecated alias, without-password), password and keyboard-interactive authentication are disabled for root. SO: if I remove the PermitRootLogin line from sshd_config, then rcctl restart sshd, then why can I see 66# sshd -T|grep -i permitr permitrootlogin yes 66# instead of prohibit-password ? Thanks!
openiked.org down?
Hello, did anyone noticed that the https://openiked.org/ is down? NO "A" record is associated with the domain? Thanks for any infos.
Blank/black screen for 6.6 - any general debugging hints?
Hello, I was using 6.5 on a desktop PC. I did a sysupgrade, but after the blue boot text, I only get black/blank screen. I don't think it is just the screen, since I cannot reach it via network. I booted the 6.6 bsd.rd then did a clean install with 6.6. The same issue. I downloaded the 6.5 bsd.rd/sets and clean installed it. IT WORKED! YAY!!! So looks like, there is some issue with 6.6 on my HW. So I will probably skip 6.6 on this HW and hope 6.7 will work :) BUT: I didn't found any MAN pages, DOCs, how to troubleshoot these kind of black/blank screen boot issues. Any hints in general, what can I do next time to avoid a clean install of the older major version? Many thanks and wishing peaceful holidays!
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" > To: "lu hu" > 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" > >> 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" > >>> 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, > &g
Re: Why isn't ChallengeResponseAuthentication NO in sshd_config?
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" > 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" > > 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! > > > > > >
Re: OpenBSD pf - redirect all DNS queries to local DNS server
rdr-to works perfectly! my hair is droppng off from the speed, without
ADs :) Many thanks. Wishing a great year-end for everybody!! Sent: Thursday,
December 19, 2019 at 8:50 PM
From: "Anthony O' Brien"
To: "lu hu"
Cc: misc@openbsd.org
Subject: Re: OpenBSD pf - redirect all DNS queries to local DNS server
Long time reader, first time writing in... > The big question: Is there
any DOC for OpenBSD about this? What pf rules > needed to redirect any
DNS server (ex.: 8.8.8.8 or 1.1.1.1) requests to the > DNS server running
on the ROUTER, coming from the CLIENTS?
You can use rdr-to[0] with pf to redirect all DNS queries to the DNS
resolver running on the router. A rule in pf.conf would look something
like:
pass in on $int_if proto { udp , tcp } from any to any port domain \
rdr-to $dns_server port domain
Ted Unangst has short write-up about turning your network inside out to
do
just this[1].
[0]: https://man.openbsd.org/pf.conf.5#rdr-to
[1]:
https://flak.tedunangst.com/post/turn-your-network-inside-out-with-one-pfconf-trick
Re: Why isn't ChallengeResponseAuthentication NO in sshd_config?
> Sent: Wednesday, December 18, 2019 at 9:49 PM > From: "Bodie" > 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! > >
Why isn't ChallengeResponseAuthentication NO in sshd_config?
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 -> 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? So please, can we make the default sshd_config more secure and set the "ChallengeResponseAuthentication to NO"? Many thanks and whishing a peaceful xmas!
OpenBSD pf - redirect all DNS queries to local DNS server
Our little home network: ISP -> ROUTER -> SWITCH -> WIFI APs -> CLIENTS ROUTER: OpenBSD 6.5, giving DHCP+fwing internet to the WIFI APs. Based on https://www.openbsd.org/faq/pf/example1.html#pf and https://www.openbsd.org/faq/pf/example1.html#dhcp CLIENTS: laptops, smartphones. So everything is going through the ROUTER. We can see a https://www.openbsd.org/faq/pf/example1.html#dns DOC for how to setup a DNS server, ~ok. AD filtering. We would like to have one, but not a fancy one, just a working one. Based on "bad hosts", ex.: if a client queries iamAD.foo, then answer it back as 127.0.0.1, so the clients will try to connect to themselfes, which will end up not showing the AD. The big question: Is there any DOC for OpenBSD about this? What pf rules needed to redirect any DNS server (ex.: 8.8.8.8 or 1.1.1.1) requests to the DNS server running on the ROUTER, coming from the CLIENTS? So ex.: if a smartphone CLIENT wants to query iamAD.foo domain to get ADs, it will only get back 127.0.0.1
