Bug #4875


Security issue with OpenSSH "ChallengeResponseAuthentication yes" (implies KbdInteractiveAuthentication yes)

Added by Maurice Smulders about 8 years ago. Updated about 8 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:


This allows the max login count to be bypassed, and lots of simultaneous dictionary password attacks can be done against SSH. The setting on pfsense is
"ChallengeResponseAuthentication yes" in /etc/ssh/sshd_config which implies that the KbdInteractiveAuthentication is yes.

This makes openssh vulnerable, and as sshd_config is generated, just fixing the actual file is not sufficient...


sshd (7.09 KB) sshd Modified /etc/sshd Maurice Smulders, 07/23/2015 08:36 PM
Actions #1

Updated by Maurice Smulders about 8 years ago

Current workarounds are:

1) Do not allow password authentication for ssh. The default setting for sshd in public key authentication is "ChallengeResponseAuthentication no" (System:Advanced, "Secure Shell")

2) edit /etc/sshd to always set these to no.

$sshconf .= "UseDNS no\n";
$sshconf .= "X11Forwarding no\n";
$sshconf .= "ChallengeResponseAuthentication no\n";
$sshconf .= "KbdInteractiveAuthentication no\n";
if (isset($config['system']['ssh']['sshdkeyonly'])) {
$sshconf .= "# Login via Key only\n";
$sshconf .= "PasswordAuthentication no\n";
$sshconf .= "PubkeyAuthentication yes\n";
} else {
$sshconf .= "# Login via Key and Password\n";
$sshconf .= "PasswordAuthentication yes\n";
$sshconf .= "PubkeyAuthentication yes\n";
$sshconf .= "# override default of no subsystems\n";
Actions #2

Updated by Kill Bill about 8 years ago

Have you actually tested this? Because, mind you, you'll get banned from the firewall:

Actions #3

Updated by Chris Buechler about 8 years ago

  • Status changed from New to Resolved
  • Priority changed from Very High to Normal
  • Target version set to 2.2.4

if/when it gets fixed upstream we'll patch it. You have the same option that everything else does - disable password auth under System>Advanced if you're concerned about it. That's enough, no need to change anything beyond that. It's not an endless number, it's up to the grace time's worth of attempts, at which point the session will end and sshlockout will have the offending IP locked out.

We talked about lowering the grace time early this week, and haven't seen any reason not to do so. That's been reduced to 30 seconds for 2.2.4 and newer.

This isn't as big of a deal as some are making it out to be. If your password's guessable in even hundreds of thousands of tries, you're doing it wrong. Not likely to get more than a few thousand out of this. And if you have SSH open to the Internet, you shouldn't be allowing password logins at all anyway.

resolved as best we can.


Also available in: Atom PDF