pap认证失败_PPP 口令认证协议 (PAP) 的配置与故障排除

点对点协议 (PPP) 目前支持两种身份验证协议：密码验证协议 (PAP) 和质询握手身份验证协议 (CHAP)。这两个协议都是在 RFC 1334 中指定的，且在同步和异步接口上都受支持。

PAP 使用双向握手为远程节点提供了建立其身份标识的简单方法。PPP链路建立阶段完成后，用户名和密码通过链路(在明文)进行不断重复发送，直到鉴权完成或连接终止为止。

PAP 是一种不安全的身份验证协议。密码以明文形式通过链路发送，对于回放和试错法攻击没有防范能力。远程节点将控制登录尝试的频率和时间。

本文档没有任何特定的要求。

本文档不限于特定的软件和硬件版本。

有关文档规则的详细信息，请参阅 Cisco 技术提示规则。

因为用户密码从未在整个连接上发送，所以CHAP被认为更加安全。有关 CHAP 的详细信息，请参阅了解和配置 PPP CHAP 身份验证。

尽管 PAP 存在缺点，其仍可用于以下环境：

当系统中安装了大量不支持 CHAP 的客户端应用程序时

当不同供应商实施的 CHAP 互不兼容时

此情况是，纯文本密码必须可用于模拟在远端主机登录。

与大多数鉴权类型一样，PAP支持双向(双程)和单向(单程)鉴权。使用单向身份验证时，仅接收呼叫的一端 (NAS) 对远程端(客户端)进行身份验证。远程客户端不对服务器进行身份验证。

通过双向认证，每边独立地发送验证请求(AUTH-RED) 并且接收认证确认(AUTH-ACK)或没有认可的验证(AUTH-NAK)。这些可以用

*Mar 6 19:18:53.322: BR0:1 PAP: O AUTH-REQid 7 len 18 from "PAPUSER"! --- Outgoing PAP AUTH-REQ. We are sending out our username (PAPUSER)and password ! --- to the NAS. The NAS will verify that the username/password is correct.*Mar 6 19:18:53.441: BR0:1 PAP: I AUTH-ACK id 7 Len 5! --- Incoming AUTH-ACK. ! --- The NAS verified the username and password and responded with an AUTH-ACK. ! --- One-way authentication is complete at this point.*Mar 6 19:18:53.445: BR0:1 PAP: I AUTH-REQ id 1 Len 14 from "NAS"! --- Incoming AUTH-REQ from the NAS. This means we now verify the identity of the NAS.*Mar 6 19:18:53.453: BR0:1 PAP: Authenticating peer NAS! --- Performing a lookup for the username (NAS) and password.*Mar 6 19:18:53.457: BR0:1 PAP: O AUTH-ACK id 1 Len 5! --- Outgoing AUTH-ACK. ! --- We have verified the username/password of the NAS and responded with an AUTH-ACK. ! --- Two-way authentication is complete.

在上述调试输出中，身份验证是双向的。然而如果配置了单向验证，我们将只能看到前二条调试线路。

如下所述，常规的 PAP 身份验证需要三个命令：

下表显示了在什么情况下要配置 callin 选项：

认证类型

客户端(主叫)

NAS(被叫)

单向

ppp authentication pap callin

ppp authentication pap

双向

ppp authentication pap

ppp authentication pap

这是本地路由器用于验证 PPP 对等体的用户名和密码。当对等体发送其PAP用户名和口令时，本地路由器将检查是否该用户名和密码在本地配置。如果匹配成功，则会验证对等体。

注意：username 命令对于 PAP 的作用不同于其对于 CHAP 的作用。通过CHAP，此用户名和口令只用于回应挑战，但PAP只用它验证流入的用户名和口令是否有效。

对于单向验证，只有被叫路由器上需要使用此命令。对于双向验证，两端都需要使用此命令。

启用出站 PAP 身份验证。

如果使用单向验证，此命令只在路由器初始呼叫的时候需要。对于双向验证，两端都必须配置此命令。

以下配置部分显示了单向身份验证情景所需的 PAP 命令。

注意：仅显示了配置的相关部分。

interface BRI0! --- BRI interface for the dialout. ip address negotiated encapsulation ppp! --- Use PPP encapsulation. This command is a required for PAP. dialer string 3785555 class 56k! --- Number to dial for the outgoing connection. dialer-group 1 isdn switch-type basic-ni isdn spid1 51299611110101 9961111 isdn spid2 51299622220101 9962222ppp authentication pap callin! --- Use PAP authentication for incoming calls. ! --- The callin keyword has made this a one-way authentication scenario. ! --- This router (client) will not request that the peer (server) authenticate ! --- itself back to the client. ppp pap sent-username PAPUSER password 7 ! --- Permit outbound authentication of this router (client) to the peer. ! --- Send a PAP AUTH-REQ packet to the peer with the username PAPUSER and password. ! --- The peer must have the username PAPUSER and password configured on it.

username PAPUSER password 0 cisco! --- Username PAPUSER is the same as the one sent by the client. ! --- Upon receiving the AUTH-REQ packet from the client, we will verify that the ! --- username and password match the one configured here.interface Serial0:23! --- This is the D-channel for the PRI on the access server receiving the call. ip unnumbered Ethernet0 no ip directed-broadcastencapsulation ppp! --- Use PPP encapsulation. This command is a required for PAP. dialer-group 1 isdn switch-type primary-ni isdn incoming-voice modem peer default ip address pool default fair-queue 64 256 0ppp authentication pap! --- Use PAP authentication for incoming calls. ! --- This router (server) will request that the peer authenticate itself to us. ! --- Note: the callin option is not used as this router is not initiating the call.

两端是否都同意将 PAP 作为身份验证方法？

如果都同意，PAP 身份验证是否成功？

maui-soho-01#show debugPPP: PPP authentication debugging is on PPP protocol negotiation debugging is onmaui-soho-01#ping 172.22.53.144Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 172.22.53.144, timeout is 2 seconds:*Mar 6 21:33:26.412: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up*Mar 6 21:33:26.432: BR0:1 PPP: Treating connection as a callout*Mar 6 21:33:26.436: BR0:1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 0 load]*Mar 6 21:33:26.440: BR0:1 PPP: No remote authentication for call-out! --- The client will not authenticate the server for an outgoing call. ! --- Remember this is a one-way authentication example.*Mar 6 21:33:26.444: BR0:1 LCP: O CONFREQ [Closed] id 82 Len 10*Mar 6 21:33:26.448: BR0:1 LCP: MagicNumber 0x2F1A7C63 (0x05062F1A7C63)! --- Outgoing CONFREQ (CONFigure-REQuest). ! --- Notice that we do not specify an authentication method, ! --- since only the peer will authenticate us.*Mar 6 21:33:26.475: BR0:1 LCP: I CONFREQ[REQsent] id 13 Len 14*Mar 6 21:33:26.479: BR0:1 LCP: AuthProto PAP(0x0304C023)! --- Incoming LCP CONFREQ (Configure-Request) indicating that ! --- the peer(server) wishes to use PAP.*Mar 6 21:33:26.483: BR0:1 LCP: MagicNumber 0x3DBEE95B (0x05063DBEE95B)*Mar 6 21:33:26.491: BR0:1 LCP: O CONFACK [REQsent] id 13 Len 14*Mar 6 21:33:26.495: BR0:1 LCP: AuthProto PAP (0x0304C023)! --- This shows the outgoing LCP CONFACK (CONFigure-ACKnowledge) indicating that ! --- the client can do PAP.*Mar 6 21:33:26.499: BR0:1 LCP: MagicNumber 0x3DBEE95B (0x05063DBEE95B)*Mar 6 21:33:26.511: BR0:1 LCP: I CONFACK [ACKsent] id 82 Len 10*Mar 6 21:33:26.515: BR0:1 LCP: MagicNumber 0x2F1A7C63 (0x05062F1.A7C63)*Mar 6 21:33:26.519: BR0:1 LCP: State is Open! --- This shows LCP negotiation is complete.*Mar 6 21:33:26.523: BR0:1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 0 load]! --- The PAP authentication (by the peer) begins.*Mar 6 21:33:26.531: BR0:1 PAP: O AUTH-REQ id 20 Len 18 from "PAPUSER"! --- The client sends out a PAP AUTH-REQ with username PAPUSER. ! --- This username is configured with the ppp pap sent-username command.*Mar 6 21:33:26.555: BR0:1 PAP: I AUTH-ACK id 20 Len 5! --- The Peer responds with a PPP AUTH-ACK, indicating that ! --- it has successfully authenticated the client.

maui-nas-06#show debugPPP: PPP authentication debugging is on PPP protocol negotiation debugging is onmaui-nas-06#*Jan 3 14:07:57.872: %LINK-3-UPDOWN: Interface Serial0:4, changed state to up*Jan 3 14:07:57.876: Se0:4 PPP: Treating connection as a callin! --- Since the connection is incoming, we will authenticate the client.*Jan 3 14:07:57.876: Se0:4 PPP: Phase is ESTABLISHING, Passive Open*Jan 3 14:07:57.876: Se0:4 LCP: State is Listen*Jan 3 14:07:58.120: Se0:4 LCP: I CONFREQ [Listen] id 83 Len 10*Jan 3 14:07:58.120: Se0:4 LCP: MagicNumber 0x2F319828 (0x05062F319828)*Jan 3 14:07:58.124: Se0:4 LCP: O CONFREQ [Listen] id 13 Len 14*Jan 3 14:07:58.124: Se0:4 LCP: AuthProto PAP(0x0304C023)! --- Outgoing CONFREQ (Configure-Request) ! --- use PAP for the peer authentication.*Jan 3 14:07:58.124: Se0:4 LCP: MagicNumber 0x3DD5D5B9 (0x05063DD5D5B9)*Jan 3 14:07:58.124: Se0:4 LCP: O CONFACK [Listen] id 83 Len 10*Jan 3 14:07:58.124: Se0:4 LCP: MagicNumber 0x2F319828 (0x05062F319828)*Jan 3 14:07:58.172: Se0:4 LCP: I CONFACK [ACKsent] id 13 Len 14*Jan 3 14:07:58.172: Se0:4 LCP: AuthProto PAP (0x0304C023)! --- This shows the incoming LCP CONFACK (Configure-Acknowledge) indicating that ! --- the client can do PAP.*Jan 3 14:07:58.172: Se0:4 LCP: MagicNumber 0x3DD5D5B9 (0x05063DD5D5B9)*Jan 3 14:07:58.172: Se0:4 LCP: State is Open*Jan 3 14:07:58.172: Se0:4 PPP: Phase is AUTHENTICATING, by this end! --- The PAP authentication (by this side) begins.*Jan 3 14:07:58.204: Se0:4 PAP: I AUTH-REQ id 21 Len 18 from "PAPUSER"! --- Incoming AUTH-REQ from the peer. This means we must now verify ! --- the identity of the peer.*Jan 3 14:07:58.204: Se0:4 PPP: Phase is FORWARDING*Jan 3 14:07:58.204: Se0:4 PPP: Phase is AUTHENTICATING*Jan 3 14:07:58.204: Se0:4 PAP: Authenticating peer PAPUSER! --- Performing a lookup for the username (PAPUSER) and password.*Jan 3 14:07:58.208: Se0:4 PAP: O AUTH-ACK id 21 Len 5! --- This shows the outgoing AUTH-ACK. ! --- We have verified the username and password and responded with an AUTH-ACK. ! --- One-way authentication is complete.

当对 PAP 进行故障排除时，请回答“调试输出”部分显示的相同问题：

两端是否都同意将 PAP 作为身份验证方法？

如果都同意，PAP 身份验证是否成功？

在特定配置中，您会发现两端没有同时达成协议将PAP当成认证协议，或者相反地，它们将CHAP当成认证协议(而此时您需要PAP)。请使用以下步骤对这些问题进行故障排除：

如果双方同意将PAP作为认证协议，但PAP连接失败，它就很可能是用户名/密码的问题。

验证主叫方正确地配置 ppp pap sent-username username password password 命令，其中用户名和密码与接受路由器上的用户名和密码匹配。

对于双向认证来说，验证接收端有正确配置的命令PPP PAP Sent-Username Username Password password ，用户名和密码与配置在主叫路由器上的命令匹配。

执行双向认证时，如果接收路由器没有出现PPP PAP Sent-Username Username Password password命令，并且PPP客户端尝试强制服务器远程鉴权，这时将显示debug ppp negotiation(或debug ppp authentication)输出。

*Jan 3 16:47:20.259: Se0:1 PAP: Failed request for PAP credentials. Username maui-nas-06

出现此错误消息表示存在配置问题，而不一定是安全漏洞。

3. 验证用户名和密码，并与对等体的PPP PAP Sent-Username Username Password Password命令中配置的用户名和密码匹配。

如果它们不匹配，您会看到以下消息：

*Jan 3 17:18:57.559: Se0:3 PAP: I AUTH-REQ id 25 Len 18 from "PAPUSER"*Jan 3 17:18:57.559: Se0:3 PPP: Phase is FORWARDING*Jan 3 17:18:57.559: Se0:3 PPP: Phase is AUTHENTICATING*Jan 3 17:18:57.559: Se0:3 PAP: Authenticating peer PAPUSER*Jan 3 17:18:57.559: Se0:3 PAP: O AUTH-NAK id 25 Len 32 msg is"Password validation failure"! --- This is an outgoing AUTH-NAK. This means that the mismatch occurred ! --- on this router. Verify that the username and password configured locally is ! --- identical to that on the peer.