测试TCP三次握手时无意间发现了一个问题：发现Telnet建立之后，Telnet Data报文中竟然可以看到交互包容内容信息。为了确认此问题，我重新操作了一遍，并记录了操作过程。

如上图，SW1作为Telnet服务器，提供Telnet服务，IP地址为10.1.1.1（vlan1），SW6作为Telnet客户端，IP地址为10.1.1.2（vlan1）。

测试1：Telnet账号密码交互是否加密

为了确认账号密码的交互报文，在SW1上创建3个账号，分别为h3c，admin和root。可以看出，这几个都是使用频率比较高的默认账号，一般是不建议使用的。如果业务网络中仍在使用，建议删除相关账号并创建新账号，避免被不法分子攻击破解。

同时，为了验证交互的密码确实是密码信息，账号配置中交叉配置密码，避免账号密码相同。

#telnet server enable#interface Vlan-interface1 ipaddress 10.1.1.1 255.255.255.0#line vty 0 63 authentication-mode scheme#local-user root class manage password simple h3c service-type telnet authorization-attribute user-role network-operator#local-user h3c class manage password simple admin service-type telnet authorization-attribute user-role network-operator#local-user admin class manage password simple root service-type telnet authorization-attribute user-role network-operator

然后开启抓包，随后在SW6开始测试登陆操作。

测试完账号登录之后，可选导出抓包文件和启动wireshark，本次启动wireshark直接查看报文。

报文截图信息如下。开始是服务器返回的登陆提示信息。

接下来输入账号密码，同时也可以看出，账号密码是一个字符一个字符进行转送的，所以密码不显示也不影响输入。接下来是第一个登陆的账号：

root/h3c

提示输入密码，接下来就是见证奇迹的时刻。

然后登陆成功，进入用户视图。

同理，其他两个账号登陆过程如下：

可见所有的账号密码信息一览无余，如果网络被监听，只用在抓包文件中筛选Telnet即可找到相关交互报文，通过login:和Password:字段即可找到相应账号信息，风险还是比较大的。

测试2：Telnet交互内容是否可见

测试完登陆，再测试一下命令操作：

输入命令和前面一样，是一个字符一个字符上传的；而返回命令则是尽可能多的整段返回的。

由此可见Telnet安全系数确实低一些，如果物理层面也不安全，那业务层面对于有些网络基础的工程师来说几乎透明。接下来再测试一下SSH交互过程。

测试3：SSH登陆报文交互情况

在设备上开启SSH服务，并给账号增加对应登陆方式。

#ssh server enable#local-user root classmanage service-type ssh#local-user h3c class manage service-type ssh#local-user admin class manage service-type ssh

从交互报文来看，除了最开始明文交互了一下协议版本信息，之后交互的所有内容都是加密的。

当然，报文交换过程中，也携带了加密算法等信息。不过，可能要破解也非等闲之辈能破解出来的，安全系数相比Telnet可算是大大提高。