【思科实验】PPP 的 CHAP 单双向认证配置

小乔

1、CHAP 认证命令：
cisco(config)#interface s0/0
cisco(config-if)#encapsulation ppp
cisco(config-if)#ppp authentication chap // 该命令只用于开启认证的服务器端，代表在接口
下开启 PPP CHAP 认证；如做双向认证，则双方都要配置该命令
2、CHAP 单向认证：（R1 为服务器端，R2 为客户端）
R1：CHAP 单向认证
conf t

username R2 password R2

int s 0/0
ip add 12.1.1.1 255.255.255.0
encapsulation ppp
ppp authentication chap

R2：CHAP 单向认证
conf t

int s 0/0
ip add 12.1.1.2 255.255.255.0
encapsulation ppp
ppp chap hostname R2
ppp chap password R2

3、CHAP 双向认证：
在 CHAP 双向认证中，可以设置认证的用户名为对方设备的 hostname，并设置相同的密码，这样就不需要在端口上配置命令 ppp chap hostname xx 和 ppp chap password xx 了。例如：

R1：CHAP 双向认证
conf t

username R2 password CCIE.LOL

int s 0/0
ip add 12.1.1.1 255.255.255.0
encapsulation ppp
ppp authentication chap

R2：CHAP 双向认证
conf t

username R1 password CCIE.LOL

int s 0/0
ip add 12.1.1.2 255.255.255.0
encapsulation ppp
ppp authentication chap

如果设置的用户名不是对方设备的 hostname 也是可以的，只要保证两边设置的密码相同即可，例如：

R1：CHAP 双向认证
conf t

username B password CCIE.LOL

int s 2/0
ip add 12.1.1.1 255.255.255.0
encapsulation ppp
ppp authentication chap
ppp chap hostname A
no sh

R2：CHAP 双向认证
conf t

username A password CCIE.LOL

int s 2/0
ip add 12.1.1.2 255.255.255.0
encapsulation ppp
ppp authentication chap
ppp chap hostname B
no sh

那能不能像下面这样配置呢？两边的用户名不相同，密码也不相同？

R1：CHAP 双向认证
conf t

username R2 password R2

int s 0/0
ip add 12.1.1.1 255.255.255.0
encapsulation ppp
ppp authentication chap
ppp chap hostname R1
ppp chap password R1

R2：CHAP 双向认证
conf t

username R1 password R1

int s 0/0
ip add 12.1.1.2 255.255.255.0
encapsulation ppp
ppp authentication chap
ppp chap hostname R2
ppp chap password R2

答案是不可以！

为什么两边的用户名和密码都不相同的时候，CHAP 建立不起来？

答：这是由 CHAP 的工作机制决定的。简要说来，CHAP 验证阶段是这样的：

服务器端主动发送验证请求，验证请求包格式：自己的主机名 | 随机码；
客户端接收到服务器端发送的验证请求后，会将请求包中的主机名和随机码提取出来，在自己的本地账号和密码中，查找与主机名匹配的密码。将匹配的密码和收到的随机码一起 hash 得到一个 hash 值，然后将自己的主机名和 hash 值发送给服务器端。
服务器端收到客户端的回应后，首先提取出主机名，查找与主机名匹配的本账号中的密码，将此密码和随机码一起 hash 得到一个 hash 值，这个 hash 值如果与接收到的 hash 值一样则验证通过。
因为 CHAP 在认证过程中，是不传递密码的，传递的是 hash 值，如果两边算得的 hash 值一致，则认证成功。既然两边都要使用密码来做 hash，所以就要求两边输入的密码必须一致。

（PS：上述验证过程摘自：http://bbs.hh010.com/thread-398405-1-1.html）

在《 CCNA 学习指南：Cisco 网络设备互连（ICND2）（第三版）》（2008 年 9 月第 1 版）这本书的第 254 页，也说明了这个问题：

《 CCNA 学习指南：Cisco 网络设备互连（ICND2）（第三版）》（2008 年 9 月第 1 版）第 254 页
《 CCNA 学习指南：Cisco 网络设备互连（ICND2）（第三版）》（2008 年 9 月第 1 版）第 254 页
接下来 Ricky 会用真机来做上述几个 CHAP 实验，来验证一下哪些是可以的，而哪些是不可以的。

实验环境：
使用两台 Cisco 2811 路由器，IOS 是目前最新的 c2800nm-adventerprisek9-mz.151-4.M10.bin
【实验】PPP 的 CHAP 单双向认证配置（用真机做）
【实验】PPP 的 CHAP 单双向认证配置（用真机做）
实验需求：
在 R1 和 R2 上做单双向 CHAP 认证。其中在做单向 CHAP 认证时，R1 是服务器端，R2 是客户端。

实验 1 —— CHAP 单向认证：
R1：CHAP 单向认证
conf t

username R2 password R2

int s 0/0/0
ip add 12.1.1.1 255.255.255.0
encapsulation ppp
ppp authentication chap
no sh

R2：CHAP 单向认证
conf t

int s 0/0/0
ip add 12.1.1.2 255.255.255.0
encapsulation ppp
ppp chap hostname R2
ppp chap password R2
no sh

看下 R2 是否能 ping 通 R1：

R2#p 12.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
可以，没问题！

实验 2 —— CHAP 双向认证（用户名使用对端 hostname，密码两边相同）：
R1：CHAP 双向认证
conf t

username R2 password CCIE.LOL

int s 0/0/0
ip add 12.1.1.1 255.255.255.0
encapsulation ppp
ppp authentication chap
no sh

R2：CHAP 双向认证
conf t

username R1 password CCIE.LOL

int s 0/0/0
ip add 12.1.1.2 255.255.255.0
encapsulation ppp
ppp authentication chap
no sh

看下 R2 是否能 ping 通 R1：

R2#p 12.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
可以，没问题！

实验 3 —— CHAP 双向认证（用户名两边自行定义，密码两边相同）：
R1：CHAP 双向认证
conf t

username B password CCIE.LOL

int s 0/0/0
ip add 12.1.1.1 255.255.255.0
encapsulation ppp
ppp authentication chap
ppp chap hostname A
no sh

R2：CHAP 双向认证
conf t

username A password CCIE.LOL

int s 0/0/0
ip add 12.1.1.2 255.255.255.0
encapsulation ppp
ppp authentication chap
ppp chap hostname B
no sh

看下 R2 是否能 ping 通 R1：

R2#p 12.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
可以，没问题！

实验 4 —— CHAP 双向认证（用户名使用对端 hostname，密码两边不相同）：
R1：CHAP 双向认证
conf t

username R2 password R2

int s 0/0/0
ip add 12.1.1.1 255.255.255.0
encapsulation ppp
ppp authentication chap
ppp chap hostname R1
ppp chap password R1
no sh

R2：CHAP 双向认证
conf t

username R1 password R1

int s 0/0/0
ip add 12.1.1.2 255.255.255.0
encapsulation ppp
ppp authentication chap
ppp chap hostname R2
ppp chap password R2
no sh

看下 R2 是否能 ping 通 R1：

R2#p 12.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.1.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
ping 不通了！

我们现在打印 debug 信息来看一下。

因为是真机实验，要想 debug 信息能输出到 telnet 上，还需要这么做：

Telnet 到 Cisco 设备的终端模式无法显示本地串口模式下的 debug 信息，需要使用以下命令：

打开终端显示：
R7#terminal monitor

打开日志功能：
R7(config)#logging on

设置日志级别为 debug 模式（7 为 debug 模式）：
R7(config)#logging monitor 7

通过以上三条命令就可以在 Telnet 终端下看到 debug 的打印信息了。
很快，你就能看到接口在不断地 up 和 down：

*Jan 15 13:26:54.939: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0,
changed state to up
*Jan 15 13:26:54.947: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0,
changed state to down
*Jan 15 13:27:03.067: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0,
changed state to up
*Jan 15 13:27:03.075: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0,
changed state to down
*Jan 15 13:27:17.243: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0,
changed state to up
*Jan 15 13:27:17.251: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0,
changed state to down
*Jan 15 13:27:23.295: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0,
changed state to up
*Jan 15 13:27:23.331: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0,
changed state to down
*Jan 15 13:27:29.435: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0,
changed state to up
*Jan 15 13:27:29.443: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0,
changed state to down
然后 debug 一下 CHAP：

R2#debug ppp authentication
很快，我们就能看到以下关于 CHAP 认证失败的 debug 信息：

R2#
*Jan 15 13:30:34.307: Se0/0/0 PPP: Using default call direction
*Jan 15 13:30:34.307: Se0/0/0 PPP: Treating connection as a dedicated line
*Jan 15 13:30:34.307: Se0/0/0 PPP: Session handle[3A0000A6] Session id[164]
*Jan 15 13:30:34.335: Se0/0/0 CHAP: O CHALLENGE id 1 len 23 from "R2"
*Jan 15 13:30:34.335: Se0/0/0 CHAP: I CHALLENGE id 1 len 23 from "R1"
*Jan 15 13:30:34.335: Se0/0/0 PPP: Sent CHAP SENDAUTH Request
*Jan 15 13:30:34.335: Se0/0/0 PPP: Received SENDAUTH Response PASS
*Jan 15 13:30:34.335: Se0/0/0 CHAP: Using hostname from interface CHAP
*Jan 15 13:30:34.335: Se0/0/0 CHAP: Using password from AAA
*Jan 15 13:30:34.339: Se0/0/0 CHAP: O RESPONSE id 1 len 23 from "R2"
*Jan 15 13:30:34.339: Se0/0/0 CHAP: I RESPONSE id 1 len 23 from "R1"
*Jan 15 13:30:34.339: Se0/0/0 PPP: Sent CHAP LOGIN Request
*Jan 15 13:30:34.343: Se0/0/0 PPP: Received LOGIN Response FAIL
*Jan 15 13:30:34.343: Se0/0/0 CHAP: O FAILURE id 1 len 25 msg is
"Authentication failed"
*Jan 15 13:30:36.351: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0,
changed state to up
*Jan 15 13:30:36.355: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0,
changed state to down
R2#
*Jan 15 13:30:38.355: Se0/0/0 PPP: Using default call direction
*Jan 15 13:30:38.355: Se0/0/0 PPP: Treating connection as a dedicated line
*Jan 15 13:30:38.355: Se0/0/0 PPP: Session handle[C10000A7] Session id[165]
*Jan 15 13:30:38.367: Se0/0/0 CHAP: O CHALLENGE id 1 len 23 from "R2"
*Jan 15 13:30:38.367: Se0/0/0 CHAP: I CHALLENGE id 1 len 23 from "R1"
*Jan 15 13:30:38.367: Se0/0/0 PPP: Sent CHAP SENDAUTH Request
*Jan 15 13:30:38.367: Se0/0/0 PPP: Received SENDAUTH Response PASS
*Jan 15 13:30:38.367: Se0/0/0 CHAP: Using hostname from interface CHAP
*Jan 15 13:30:38.367: Se0/0/0 CHAP: Using password from AAA
*Jan 15 13:30:38.367: Se0/0/0 CHAP: O RESPONSE id 1 len 23 from "R2"
*Jan 15 13:30:38.371: Se0/0/0 CHAP: I RESPONSE id 1 len 23 from "R1"
*Jan 15 13:30:38.371: Se0/0/0 PPP: Sent CHAP LOGIN Request
*Jan 15 13:30:38.375: Se0/0/0 PPP: Received LOGIN Response FAIL
*Jan 15 13:30:38.375: Se0/0/0 CHAP: O FAILURE id 1 len 25 msg is
"Authentication failed"
*Jan 15 13:30:40.383: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0,
changed state to up
*Jan 15 13:30:40.387: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0,
changed state to down
实验 5 —— CHAP 双向认证（用户名使用对端 hostname，密码两边不相同，但密码两边都有）：
根据 CHAP 验证机制来看，实验 4 之所以验证失败，是因为本端的数据库里没有对端的密码，从而无法进行 hash 造成的。那如果本端的数据库有对端的密码呢？

R1：CHAP 双向认证
conf t

username R1 password R1
username R2 password R2

int s 0/0/0
ip add 12.1.1.1 255.255.255.0
encapsulation ppp
ppp authentication chap
ppp chap hostname R1
ppp chap password R1
no sh

R2：CHAP 双向认证
conf t

username R1 password R1
username R2 password R2

int s 0/0/0
ip add 12.1.1.2 255.255.255.0
encapsulation ppp
ppp authentication chap
ppp chap hostname R2
ppp chap password R2
no sh

看下 R2 是否能 ping 通 R1：

R2#p 12.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.1.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
还是不可以！端口照样在不断地 up 和 down，debug 信息也显示验证失败，可能验证的时候，还是需要两边的密码必须保持一致！

welinker448

welinker448