豆渣搅拌机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 NA
S.*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-chann
el 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 lo
ad]! --- 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)。请使⽤以下步骤对这些问题进⾏故障排除：pcu h
如果双⽅同意将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.
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议