Bug #4875
closedSecurity issue with OpenSSH "ChallengeResponseAuthentication yes" (implies KbdInteractiveAuthentication yes)
0%
Description
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...
Files
Updated by Maurice Smulders over 9 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";
Updated by Kill Bill over 9 years ago
Have you actually tested this? Because, mind you, you'll get banned from the firewall: https://doc.pfsense.org/index.php/Sshlockout
Updated by Chris Buechler over 9 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.