Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Match vs. ChallengeResponseAuthentication?

40 views
Skip to first unread message

Chris Pepper

unread,
Oct 29, 2009, 12:01:59 PM10/29/09
to
Hello,

We'd like to allow passwords only from the local network, and allow public key auth from on-campus or off-campus. The server runs SuSE Linux, and we might do the same on RHEL/CentOS & Mac OS X if we can get it to work.

Unfortunately, Match allows PasswordAuthentication but not ChallengeResponseAuthentication. Is there any reason ChallengeResponseAuthentication cannot be supported in this context?

Plan B is to run 2 different sshd servers on different ports, and direct users to the appropriate one via iptables, but that's much more complicated.

Thanks,

Chris

--
Chris Pepper: <http://cbio.mskcc.org/>
<http://www.extrapepperoni.com/>
_______________________________________________
openssh-unix-dev mailing list
openssh-...@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Damien Miller

unread,
Oct 29, 2009, 8:15:08 PM10/29/09
to
On Thu, 29 Oct 2009, Chris Pepper wrote:

> Hello,
>
> We'd like to allow passwords only from the local network, and allow
> public key auth from on-campus or off-campus. The server runs SuSE Linux, and
> we might do the same on RHEL/CentOS & Mac OS X if we can get it to work.
>
> Unfortunately, Match allows PasswordAuthentication but not
> ChallengeResponseAuthentication. Is there any reason
> ChallengeResponseAuthentication cannot be supported in this context?

If you are using SSH protocol 2 only, then you can turn off
KbdInteractiveAuthentication inside match. Otherwise, try this diff:


Index: servconf.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/servconf.c,v
retrieving revision 1.196
diff -u -p -r1.196 servconf.c
--- servconf.c 8 Oct 2009 14:03:41 -0000 1.196
+++ servconf.c 30 Oct 2009 00:13:25 -0000
@@ -333,8 +333,8 @@ static struct {
#endif
{ "passwordauthentication", sPasswordAuthentication, SSHCFG_ALL },
{ "kbdinteractiveauthentication", sKbdInteractiveAuthentication, SSHCFG_ALL },
- { "challengeresponseauthentication", sChallengeResponseAuthentication, SSHCFG_GLOBAL },
- { "skeyauthentication", sChallengeResponseAuthentication, SSHCFG_GLOBAL }, /* alias */
+ { "challengeresponseauthentication", sChallengeResponseAuthentication, SSHCFG_ALL },
+ { "skeyauthentication", sChallengeResponseAuthentication, SSHCFG_ALL }, /* alias */
#ifdef JPAKE
{ "zeroknowledgepasswordauthentication", sZeroKnowledgePasswordAuthentication, SSHCFG_ALL },
#else
@@ -1347,6 +1347,7 @@ copy_set_server_options(ServerOptions *d
M_CP_INTOPT(kerberos_authentication);
M_CP_INTOPT(hostbased_authentication);
M_CP_INTOPT(kbd_interactive_authentication);
+ M_CP_INTOPT(challenge_response_authentication);
M_CP_INTOPT(zero_knowledge_password_authentication);
M_CP_INTOPT(permit_root_login);
M_CP_INTOPT(permit_empty_passwd);
Index: sshd_config.5
===================================================================
RCS file: /cvs/src/usr.bin/ssh/sshd_config.5,v
retrieving revision 1.109
diff -u -p -r1.109 sshd_config.5
--- sshd_config.5 8 Oct 2009 20:42:13 -0000 1.109
+++ sshd_config.5 30 Oct 2009 00:13:25 -0000
@@ -602,6 +602,7 @@ Available keywords are
.Cm AllowAgentForwarding ,
.Cm AllowTcpForwarding ,
.Cm Banner ,
+.Cm ChallengeResponseAuthentication ,
.Cm ChrootDirectory ,
.Cm ForceCommand ,
.Cm GatewayPorts ,

Darren Tucker

unread,
Oct 29, 2009, 8:55:49 PM10/29/09
to
Damien Miller wrote:
> On Thu, 29 Oct 2009, Chris Pepper wrote:
>
>> Hello,
>>
>> We'd like to allow passwords only from the local network, and allow
>> public key auth from on-campus or off-campus. The server runs SuSE Linux, and
>> we might do the same on RHEL/CentOS & Mac OS X if we can get it to work.
>>
>> Unfortunately, Match allows PasswordAuthentication but not
>> ChallengeResponseAuthentication. Is there any reason
>> ChallengeResponseAuthentication cannot be supported in this context?
>
> If you are using SSH protocol 2 only, then you can turn off
> KbdInteractiveAuthentication inside match. Otherwise, try this diff:

Conversely, if you're willing to require SSHv2 clients for CR-based
authentication you can turn off ChallengeResponseAuthentication globally
and enable KbdInteractiveAuthentication for v2 clients your local
networks, eg


ChallengeResponseAuthentication no
KbdInteractiveAuthentication no
Match Address 10.0.0.0/8
KbdInteractiveAuthentication yes


Originally ChallengeResponseAuthentication was omitted because it has
slightly odd semantics. In sshd.c:

/* Fill in default values for those options not explicitly set. */
fill_default_server_options(&options);

/* challenge-response is implemented via keyboard interactive */
if (options.challenge_response_authentication)
options.kbd_interactive_authentication = 1;

If we're going to enable it we need to think through the use cases and
make sure it adheres the principle of least surprise :-)

--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Damien Miller

unread,
Oct 29, 2009, 9:13:29 PM10/29/09
to
On Fri, 30 Oct 2009, Darren Tucker wrote:

> ChallengeResponseAuthentication no
> KbdInteractiveAuthentication no
> Match Address 10.0.0.0/8
> KbdInteractiveAuthentication yes
>
>
> Originally ChallengeResponseAuthentication was omitted because it has slightly
> odd semantics. In sshd.c:
>
> /* Fill in default values for those options not explicitly set. */
> fill_default_server_options(&options);
>
> /* challenge-response is implemented via keyboard interactive */
> if (options.challenge_response_authentication)
> options.kbd_interactive_authentication = 1;
>
> If we're going to enable it we need to think through the use cases and make
> sure it adheres the principle of least surprise :-)

Good point. I just noticed that we don't document
KbdInteractiveAuthentication in sshd_config(5). Maybe we should deprecate
it by making it a pointer to ChallengeResponseAutentication like
SkeyAuthentication already is?

-d

Chris Pepper

unread,
Nov 2, 2009, 5:14:08 PM11/2/09
to
Damien Miller wrote:
> On Fri, 30 Oct 2009, Darren Tucker wrote:
>
>> ChallengeResponseAuthentication no
>> KbdInteractiveAuthentication no
>> Match Address 10.0.0.0/8
>> KbdInteractiveAuthentication yes
>>
>>
>> Originally ChallengeResponseAuthentication was omitted because it has slightly
>> odd semantics. In sshd.c:
>>
>> /* Fill in default values for those options not explicitly set. */
>> fill_default_server_options(&options);
>>
>> /* challenge-response is implemented via keyboard interactive */
>> if (options.challenge_response_authentication)
>> options.kbd_interactive_authentication = 1;
>>
>> If we're going to enable it we need to think through the use cases and make
>> sure it adheres the principle of least surprise :-)
>
> Good point. I just noticed that we don't document
> KbdInteractiveAuthentication in sshd_config(5). Maybe we should deprecate
> it by making it a pointer to ChallengeResponseAutentication like
> SkeyAuthentication already is?

We don't allow v1, but I got it working on CentOS through iptables, so didn't have to build a custom sshd v5. Now I get to fight with SuSE's insane iptables implementation.

Please tell me if I said anything bogus (especially as I didn't actually test the Match configuration)!

http://www.extrapepperoni.com/post/2009/11/Conditional-%60ssh%60-Configuration%3A-%60iptables%60-%60sshd%60

Thanks much,

Chris Pepper

--
Chris Pepper: <http://cbio.mskcc.org/>
<http://www.extrapepperoni.com/>

0 new messages