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!