* Re: pppd against RADIUS
2009-07-17 16:15 pppd against RADIUS David Leon
@ 2009-07-17 17:33 ` James Carlson
2009-07-17 18:19 ` David Leon
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: James Carlson @ 2009-07-17 17:33 UTC (permalink / raw)
To: linux-ppp
David Leon wrote:
> I need some help. I'm dialing out to a "closed network" to make a ppp
> link, but have to authenticate against a remote RADIUS server on that
> network.
>
> I connected manually using minicom and I already have the ppp-on and
> ppp-on-dialer scripts working ok. I have to authenticate twice. Fist
> time to get access to the router, and execute ppp manually, wich the
> script already done, and the authentiocate ppp against the RADIUS
> server wich I don't have a clue how can I do that.
You'll probably need to provide more details, such as your configuration
files, the exact command sequence you're using, and the messages and/or
errors you see.
In general, if a remote PPP access device ("server") is using RADIUS,
then that's no concern of yours as you authenticate to it. You just set
up your PAP or CHAP credentials as usual for PPP, and it's the peer's
responsibility to contact the RADIUS server on your behalf in order to
verify your identity.
Dial-out clients don't typically run RADIUS. It doesn't make sense, as
RADIUS is a mechanism that (among other things) allows you to validate
someone else's identity. That's why it's used on the dial-in "server"
side of the connection.
(If it helps, you can think of RADIUS as being a little like NIS, LDAP,
Active Directory, or even PAM. As a user logging into the system, you
don't really have to know where the server is or much about it. You
just have to provide your credentials using whatever the _local_
protocol is.)
--
James Carlson 42.703N 71.076W <carlsonj@workingcode.com>
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: pppd against RADIUS
2009-07-17 16:15 pppd against RADIUS David Leon
2009-07-17 17:33 ` James Carlson
@ 2009-07-17 18:19 ` David Leon
2009-07-17 18:48 ` James Carlson
2009-07-20 12:34 ` David Leon
3 siblings, 0 replies; 5+ messages in thread
From: David Leon @ 2009-07-17 18:19 UTC (permalink / raw)
To: linux-ppp
Hi James
Sorry for my bad English. In fact, your example about RADIUS server
it's very clear to me, I just wanted to ad the detail that the remote
peer is using it as an authentication squeme. I'm including the
scripts and see if you can help me out. I'm really new on this pppd
stuff.
I'm passing all pppd parameters in command line, so my
/etc/ppp/options is blank. See my config files and a log at the end
I hope you can help me out.
Thanks
David
*******************
/etc/ppp/scripts/ppp-on
*******************
#!/bin/sh
#
# Script to initiate a ppp connection. This is the first part of the
# pair of scripts. This is not a secure pair of scripts as the codes
# are visible with the 'ps' command. However, it is simple.
#
# These are the parameters. Change as needed.
TELEPHONEU5555 # The telephone number for the connection
ACCOUNT=myusername # The account name for logon (as in 'George Burns')
PASSWORD=mypassword # The password for this account (and 'Gracie Allen')
LOCAL_IP=0.0.0.0 # Local IP address if known. Dynamic = 0.0.0.0
REMOTE_IP=0.0.0.0 # Remote IP address if desired. Normally 0.0.0.0
NETMASK%5.255.255.0 # The proper netmask if needed
#
# Export them so that they will be available at 'ppp-on-dialer' time.
export TELEPHONE ACCOUNT PASSWORD
#
# This is the location of the script which dials the phone and logs
# in. Please use the absolute file name as the $PATH variable is not
# used on the connect option. (To do so on a 'root' account would be
# a security hole so don't ask.)
#
DIALER_SCRIPT=/etc/ppp/scripts/ppp-on-dialer
#
# Initiate the connection
#
# I put most of the common options on this command. Please, don't
# forget the 'lock' option or some programs such as mgetty will not
# work. The asyncmap and escape will permit the PPP link to work with
# a telnet or rlogin connection. You are welcome to make any changes
# as desired. Don't use the 'defaultroute' option if you currently
# have a default route to an ethernet gateway.
#
exec /usr/sbin/pppd debug lock modem crtscts /dev/ttyS0 115200 plugin
radius.so \
$LOCAL_IP:$REMOTE_IP noipdefault defaultroute connect $DIALER_SCRIPT
*******************
/etc/ppp/scripts/ppp-on-dialer
*******************
#!/bin/sh
#
# This is part 2 of the ppp-on script. It will perform the connection
# protocol for the desired connection.
#
exec chat -v \
TIMEOUT 10 \
ABORT '\nBUSY\r' \
ABORT '\nNO ANSWER\r' \
ABORT '\nRINGING\r\n\r\nRINGING\r' \
'' \rAT \
'OK-+++\c-OK' ATH0 \
TIMEOUT 60 \
OK ATDT$TELEPHONE \
CONNECT '' \
sername: $ACCOUNT \
assword: $PASSWORD \
DPSCFR--DPSCFR ppp \
~ ''
*******************
/etc/ppp/scripts/ppp-off
*******************
#!/bin/sh
######################################################################
#
# Determine the device to be terminated.
#
if [ "$1" = "" ]; then
DEVICE=ppp0
else
DEVICE=$1
fi
######################################################################
#
# If the ppp0 pid file is present then the program is running. Stop it.
if [ -r /var/run/$DEVICE.pid ]; then
kill -INT `cat /var/run/$DEVICE.pid`
#
# If the kill did not work then there is no process running for this
# pid. It may also mean that the lock file will be left. You may wish
# to delete the lock file at the same time.
if [ ! "$?" = "0" ]; then
rm -f /var/run/$DEVICE.pid
echo "ERROR: Removed stale pid file"
exit 1
fi
#
# Success. Let pppd clean up its own junk.
echo "PPP link to $DEVICE terminated."
exit 0
fi
#
# The ppp process is not running for ppp0
echo "ERROR: PPP link is not active on $DEVICE"
exit 1
*******************
/etc/ppp/pap-secret
*******************
#User Server Secret IP Address
#bob * mypassword *
myusername * mypassword *
*************************************************************
LOG /var/log/messages
Jul 17 14:17:35 linux pppd[17848]: Plugin radius.so loaded.
Jul 17 14:17:35 linux pppd[17848]: RADIUS plugin initialized.
Jul 17 14:17:35 linux kernel: CSLIP: code copyright 1989 Regents of
the University of California
Jul 17 14:17:35 linux kernel: PPP generic driver version 2.4.2
Jul 17 14:17:35 linux pppd[17856]: pppd 2.4.4 started by root, uid 0
Jul 17 14:17:36 linux chat[17860]: timeout set to 10 seconds
Jul 17 14:17:36 linux chat[17860]: abort on (\nBUSY\r)
Jul 17 14:17:36 linux chat[17860]: abort on (\nNO ANSWER\r)
Jul 17 14:17:36 linux chat[17860]: abort on (\nRINGING\r\n\r\nRINGING\r)
Jul 17 14:17:36 linux chat[17860]: send (rAT^M)
Jul 17 14:17:36 linux chat[17860]: expect (OK)
Jul 17 14:17:36 linux chat[17860]: rAT^M^M
Jul 17 14:17:36 linux chat[17860]: OK
Jul 17 14:17:36 linux chat[17860]: -- got it
Jul 17 14:17:36 linux chat[17860]: send (ATH0^M)
Jul 17 14:17:36 linux chat[17860]: timeout set to 60 seconds
Jul 17 14:17:36 linux chat[17860]: expect (OK)
Jul 17 14:17:36 linux chat[17860]: ^M
Jul 17 14:17:36 linux chat[17860]: ATH0^M^M
Jul 17 14:17:36 linux chat[17860]: OK
Jul 17 14:17:36 linux chat[17860]: -- got it
Jul 17 14:17:36 linux chat[17860]: send (ATDT555555^M)
Jul 17 14:17:36 linux chat[17860]: expect (CONNECT)
Jul 17 14:17:36 linux chat[17860]: ^M
Jul 17 14:17:57 linux chat[17860]: ATDT686140^M^M
Jul 17 14:17:57 linux chat[17860]: CONNECT
Jul 17 14:17:57 linux chat[17860]: -- got it
Jul 17 14:17:57 linux chat[17860]: send (^M)
Jul 17 14:17:57 linux chat[17860]: expect (sername:)
Jul 17 14:17:57 linux chat[17860]: 115200^M
Jul 17 14:17:58 linux chat[17860]: CC^M
Jul 17 14:17:58 linux chat[17860]: ^M
Jul 17 14:17:58 linux chat[17860]: Bienvenidos al router DPSC!!!^M
Jul 17 14:17:58 linux chat[17860]: ^M
Jul 17 14:17:58 linux chat[17860]: Username:
Jul 17 14:17:58 linux chat[17860]: -- got it
Jul 17 14:17:58 linux chat[17860]: send (myusername^M)
Jul 17 14:17:58 linux chat[17860]: expect (assword:)
Jul 17 14:17:59 linux chat[17860]: myusername^M
Jul 17 14:17:59 linux chat[17860]: Password:
Jul 17 14:17:59 linux chat[17860]: -- got it
Jul 17 14:17:59 linux chat[17860]: send (mypassword*^M)
Jul 17 14:17:59 linux chat[17860]: expect (DPSCFR)
Jul 17 14:18:00 linux chat[17860]: ^M
Jul 17 14:18:00 linux chat[17860]: ^M
Jul 17 14:18:00 linux chat[17860]: RouterDPSCFR
Jul 17 14:18:00 linux chat[17860]: -- got it
Jul 17 14:18:00 linux chat[17860]: send (ppp^M)
Jul 17 14:18:00 linux chat[17860]: expect (/root)
Jul 17 14:18:00 linux chat[17860]: >ppp^M
Jul 17 14:18:00 linux chat[17860]: Entering PPP mode.^M
Jul 17 14:18:00 linux chat[17860]: Async interface address is
unnumbered (Ethernet0)^M
Jul 17 14:18:00 linux chat[17860]: Your IP address is 172.28.7.208.
MTU is 1500 bytes^M
Jul 17 14:18:00 linux chat[17860]: Header compression will match your system.^M
Jul 17 14:18:00 linux chat[17860]: ^M
Jul 17 14:18:04 linux chat[17860]: ~~^?}#@!}!(} }8}"}&} }*} }
}#}$@#}%}&_}8W}0}'}"}(}"}2}0~~^?}#@!}!)} }8}"}&} }*} }
Jul 17 14:18:06 linux chat[17860]:
}#}$@#}%}&_}8W}0}'}"}(}"[^Y~~^?}#@!}!*} }8}"}&} }*} }
}#}$@#}%}&_}8W}0}'}"}(}"^Q}+~
Jul 17 14:18:10 linux chat[17860]: ~^?}#@!}!+} }8}"}&} }*} }
}#}$@#}%}&_}8W}0}'}"}(}"X^B~~^?}#@!}!,} }8}"}&} }*} } }#}
Jul 17 14:18:14 linux chat[17860]:
$@#}%}&_}8W}0}'}"}(}"}4'~~^?}#@!}!-} }8}"}&} }*} }
}#}$@#}%}&_}8W}0}'}"}(}"].~~^?}
Jul 17 14:18:16 linux chat[17860]: #@!}!.} }8}"}&} }*} }
}#}$@#}%}&_}8W}0}'}"}(}"^W<~~^?}#@!}!/} }8}"}&} }*} } }#}$@#
Jul 17 14:18:20 linux chat[17860]: }%}&_}8W}0}'}"}(}"^5~~^?}#@!}!0}
}8}"}&} }*} } }#}$@#}%}&_}8W}0}'}"}(}"}&"~~^?}#@!
Jul 17 14:18:22 linux chat[17860]: }!1} }8}"}&} }*} }
}#}$@#}%}&_}8W}0}'}"}(}"O+~~^?}#@!}!2} }8}"}&} }*} } }#}$@#}%}
Jul 17 14:18:26 linux chat[17860]: &_}8W}0}'}"}(}"^E9~^M
Jul 17 14:18:26 linux chat[17860]: NO CARRIER^M
On 7/17/09, James Carlson <carlsonj@workingcode.com> wrote:
> David Leon wrote:
>> I need some help. I'm dialing out to a "closed network" to make a ppp
>> link, but have to authenticate against a remote RADIUS server on that
>> network.
>>
>> I connected manually using minicom and I already have the ppp-on and
>> ppp-on-dialer scripts working ok. I have to authenticate twice. Fist
>> time to get access to the router, and execute ppp manually, wich the
>> script already done, and the authentiocate ppp against the RADIUS
>> server wich I don't have a clue how can I do that.
>
> You'll probably need to provide more details, such as your configuration
> files, the exact command sequence you're using, and the messages and/or
> errors you see.
>
> In general, if a remote PPP access device ("server") is using RADIUS,
> then that's no concern of yours as you authenticate to it. You just set
> up your PAP or CHAP credentials as usual for PPP, and it's the peer's
> responsibility to contact the RADIUS server on your behalf in order to
> verify your identity.
>
> Dial-out clients don't typically run RADIUS. It doesn't make sense, as
> RADIUS is a mechanism that (among other things) allows you to validate
> someone else's identity. That's why it's used on the dial-in "server"
> side of the connection.
>
> (If it helps, you can think of RADIUS as being a little like NIS, LDAP,
> Active Directory, or even PAM. As a user logging into the system, you
> don't really have to know where the server is or much about it. You
> just have to provide your credentials using whatever the _local_
> protocol is.)
>
> --
> James Carlson 42.703N 71.076W <carlsonj@workingcode.com>
>
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: pppd against RADIUS
2009-07-17 16:15 pppd against RADIUS David Leon
2009-07-17 17:33 ` James Carlson
2009-07-17 18:19 ` David Leon
@ 2009-07-17 18:48 ` James Carlson
2009-07-20 12:34 ` David Leon
3 siblings, 0 replies; 5+ messages in thread
From: James Carlson @ 2009-07-17 18:48 UTC (permalink / raw)
To: linux-ppp
David Leon wrote:
> exec /usr/sbin/pppd debug lock modem crtscts /dev/ttyS0 115200 plugin
> radius.so \
> $LOCAL_IP:$REMOTE_IP noipdefault defaultroute connect $DIALER_SCRIPT
Unless the system running this script is itself the remote dial-in host
(which seems unlikely, given the context), that command is incorrect.
You should *not* be including the radius.so plugin. Remove that.
You're not authenticating your peer using a local RADIUS server on your
side of the link -- quite the opposite; the remote peer is doing that.
In general, you shouldn't have to use $LOCAL_IP:$REMOTE_IP if you're a
regular dial-up client ... but I don't know much about these
vendor-supplied scripts.
You also seem to be missing "user myusername" in the configuration.
Unless the user name you use to log into PPP on that peer happens to be
identically the name of your local host, this probably won't work.
> exec chat -v \
> TIMEOUT 10 \
> ABORT '\nBUSY\r' \
> ABORT '\nNO ANSWER\r' \
> ABORT '\nRINGING\r\n\r\nRINGING\r' \
> '' \rAT \
> 'OK-+++\c-OK' ATH0 \
> TIMEOUT 60 \
> OK ATDT$TELEPHONE \
> CONNECT '' \
> sername: $ACCOUNT \
> assword: $PASSWORD \
> DPSCFR--DPSCFR ppp \
> ~ ''
That almost looks like an OK script, assuming that you really have to do
a text mode log-in before starting PPP. But see the note further below
-- you're being hurt by your choice of shell, and that's why it's not
working.
One note on it, though: you're not initializing the modem. Good
practice usually includes initializing the modem properly. (Usually
with at least "AT&F" for generic modems, and "AT&F1" for USR brand
modems. Your mileage will vary; see the documentation for your modem.)
> LOG /var/log/messages
This is the key part of any request for pppd help. ;-}
> Jul 17 14:18:00 linux chat[17860]: expect (/root)
> Jul 17 14:18:00 linux chat[17860]: >ppp^M
> Jul 17 14:18:00 linux chat[17860]: Entering PPP mode.^M
> Jul 17 14:18:00 linux chat[17860]: Async interface address is
> unnumbered (Ethernet0)^M
> Jul 17 14:18:00 linux chat[17860]: Your IP address is 172.28.7.208.
> MTU is 1500 bytes^M
> Jul 17 14:18:00 linux chat[17860]: Header compression will match your system.^M
> Jul 17 14:18:00 linux chat[17860]: ^M
> Jul 17 14:18:04 linux chat[17860]: ~~^?}#@!}!(} }8}"}&} }*} }
> }#}$@#}%}&_}8W}0}'}"}(}"}2}0~~^?}#@!}!)} }8}"}&} }*} }
> Jul 17 14:18:06 linux chat[17860]:
Oops. Your chat script is wrong. That "garbage" text is actually PPP
from the peer.
Your shell is expanding "~" on the command line into "/root", and the
peer never sends that string, so the chat script doesn't ever exit.
Change the last line of the chat script to read:
'~' ''
Note the quotes around '~' -- to stop the shell expansion. Better still
would be something like this:
'PPP mode' ''
Instead of expecting the '~' character (the start of the first PPP
message from the peer), you can just expect the notification that PPP is
starting. That's enough, and it should make the connection complete
faster because you will be less likely to lose that first message and
require a retransmit.
For what it's worth, it's good practice to put your chat script into a
separate file, and then use chat's "-f" option to read that file. Doing
that avoids a host of shell-related hysteria.
--
James Carlson 42.703N 71.076W <carlsonj@workingcode.com>
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: pppd against RADIUS
2009-07-17 16:15 pppd against RADIUS David Leon
` (2 preceding siblings ...)
2009-07-17 18:48 ` James Carlson
@ 2009-07-20 12:34 ` David Leon
3 siblings, 0 replies; 5+ messages in thread
From: David Leon @ 2009-07-20 12:34 UTC (permalink / raw)
To: linux-ppp
Carlson thanks for your comments and ideas. I will change the sripts
following your advice. Thanks. I will keep you posted.
David
On 7/17/09, James Carlson <carlsonj@workingcode.com> wrote:
> David Leon wrote:
>> exec /usr/sbin/pppd debug lock modem crtscts /dev/ttyS0 115200 plugin
>> radius.so \
>> $LOCAL_IP:$REMOTE_IP noipdefault defaultroute connect $DIALER_SCRIPT
>
> Unless the system running this script is itself the remote dial-in host
> (which seems unlikely, given the context), that command is incorrect.
> You should *not* be including the radius.so plugin. Remove that.
> You're not authenticating your peer using a local RADIUS server on your
> side of the link -- quite the opposite; the remote peer is doing that.
>
> In general, you shouldn't have to use $LOCAL_IP:$REMOTE_IP if you're a
> regular dial-up client ... but I don't know much about these
> vendor-supplied scripts.
>
> You also seem to be missing "user myusername" in the configuration.
> Unless the user name you use to log into PPP on that peer happens to be
> identically the name of your local host, this probably won't work.
>
>> exec chat -v \
>> TIMEOUT 10 \
>> ABORT '\nBUSY\r' \
>> ABORT '\nNO ANSWER\r' \
>> ABORT '\nRINGING\r\n\r\nRINGING\r' \
>> '' \rAT \
>> 'OK-+++\c-OK' ATH0 \
>> TIMEOUT 60 \
>> OK ATDT$TELEPHONE \
>> CONNECT '' \
>> sername: $ACCOUNT \
>> assword: $PASSWORD \
>> DPSCFR--DPSCFR ppp \
>> ~ ''
>
> That almost looks like an OK script, assuming that you really have to do
> a text mode log-in before starting PPP. But see the note further below
> -- you're being hurt by your choice of shell, and that's why it's not
> working.
>
> One note on it, though: you're not initializing the modem. Good
> practice usually includes initializing the modem properly. (Usually
> with at least "AT&F" for generic modems, and "AT&F1" for USR brand
> modems. Your mileage will vary; see the documentation for your modem.)
>
>> LOG /var/log/messages
>
> This is the key part of any request for pppd help. ;-}
>
>> Jul 17 14:18:00 linux chat[17860]: expect (/root)
>> Jul 17 14:18:00 linux chat[17860]: >ppp^M
>> Jul 17 14:18:00 linux chat[17860]: Entering PPP mode.^M
>> Jul 17 14:18:00 linux chat[17860]: Async interface address is
>> unnumbered (Ethernet0)^M
>> Jul 17 14:18:00 linux chat[17860]: Your IP address is 172.28.7.208.
>> MTU is 1500 bytes^M
>> Jul 17 14:18:00 linux chat[17860]: Header compression will match your
>> system.^M
>> Jul 17 14:18:00 linux chat[17860]: ^M
>> Jul 17 14:18:04 linux chat[17860]: ~~^?}#@!}!(} }8}"}&} }*} }
>> }#}$@#}%}&_}8W}0}'}"}(}"}2}0~~^?}#@!}!)} }8}"}&} }*} }
>> Jul 17 14:18:06 linux chat[17860]:
>
> Oops. Your chat script is wrong. That "garbage" text is actually PPP
> from the peer.
>
> Your shell is expanding "~" on the command line into "/root", and the
> peer never sends that string, so the chat script doesn't ever exit.
> Change the last line of the chat script to read:
>
> '~' ''
>
> Note the quotes around '~' -- to stop the shell expansion. Better still
> would be something like this:
>
> 'PPP mode' ''
>
> Instead of expecting the '~' character (the start of the first PPP
> message from the peer), you can just expect the notification that PPP is
> starting. That's enough, and it should make the connection complete
> faster because you will be less likely to lose that first message and
> require a retransmit.
>
> For what it's worth, it's good practice to put your chat script into a
> separate file, and then use chat's "-f" option to read that file. Doing
> that avoids a host of shell-related hysteria.
>
> --
> James Carlson 42.703N 71.076W <carlsonj@workingcode.com>
>
^ permalink raw reply [flat|nested] 5+ messages in thread