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
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.
####################
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?
Many thanks and whishing a peaceful xmas!
