CN105704091A - 一种基于ssh协议的会话解析方法及系统 - Google Patents

Abstract

本发明提出了一种基于SSH协议的会话解析方法及系统，所述方法包含：步骤101)接收基于SSH协议会话的数据包，并对接收的数据包分别进行如下预处理：当一个数据包包含若干条完整的消息时，从该数据包中依次提取出每一条完整的消息；当一个数据包所含的消息不完整时，首先将当前数据包包含的不完整的消息进行缓存，然后接收后续的数据包，最后将后续数据包包含的消息和缓存的消息内容进行拼接，直至拼接出一条完整的消息；步骤102)从得到的各条完整的消息中提取与生成日志相关的内容，并按照设定的格式封装与日志相关的内容，进而得到解析日志完成会话解析。本发明的技术能实现基于SSH会话的审计，可以为诸如银行等机构提供安全保障。

Description

一种基于SSH协议的会话解析方法及系统

技术领域

本发明属于计算机网络技术领域，具体涉及到一种基于SSH协议的会话解析方法及系统。

背景技术

协议是各种计算机应用中及应用间通信的方式，协议解析已成为网络应用中不可或缺的技术。通信双方将通信内容封装在协议中进行传输，某些协议还对传输的数据进行加密，如SSH协议，它是在不安全的网络上进行安全远程登录和其他安全网络服务的协议，通过SSH信道传输的数据均为加密数据。

在某些企业或机构的业务系统中，需要对用户端的登陆和操作行为进行监控和记录，用于业务审计。而对用户行为的监控一般采用在服务端和客户端之间加入中间人来实现，对于SSH协议而言，中间人截获的数据包均为加密内容，需要先将其解密为明文数据包，再对明文数据包进行解析，解析之后生成解析日志，审计人员可以通过解析日志重现客户端的所有操作行为，从而为这些企业或机构的业务系统提供了安全保障。审计的目的在于不影响客户端和服务器之间正常通信质量的前提下对客户端行为进行监控，中间人的处理效率会影响到客户端和服务端的通信质量，而协议解析是中间人处理很重要的一步，这对协议解析的效率也提出了更高的要求。目前，基于SSH协议的解析较少，现有协议解析技术往往都只适用于一些预设的固定场景，可扩展性较差。此外，当前方法还是以纯软的解析方式为主，并发性能还有待提高。

发明内容

本发明的目的在于，为了为某些企业或机构的业务系统提供审计支持，从而提出了一种基于SSH协议的会话解析方法及系统。

为了实现上述目的，本发明提供一种基于SSH协议的会话解析方法，所述方法包含：

步骤101)接收基于SSH协议会话的数据包，并对接收的数据包分别进行如下预处理：

当一个数据包包含若干条完整的消息时，从该数据包中依次提取出每一条完整的消息；

当一个数据包所含的消息不完整时，首先将当前数据包包含的不完整的消息进行缓存，然后接收后续的数据包，最后将后续数据包包含的消息和缓存的消息内容进行拼接，直至拼接出一条完整的消息；

步骤102)从得到的各条完整的消息中提取与生成日志相关的内容，并按照设定的格式封装与日志相关的内容，进而得到解析日志完成会话解析。

可选的，上述步骤102)之后还包含：

步骤103)将生成的解析日志采用流式发送模式发送至日志服务器；

其中，所述的流式发送模式为：将生成的解析日志写入日志缓存中，当缓存的日志长度达到设定的发送长度时，立即向日志服务器发送解析日志信息。

可选的，上述步骤101)进一步包含：

步骤101-1)当收到一个基于SSH协议会话的数据包后，首先查看缓存区是否有缓存数据包，若不存在缓存数据包，则直接计算接收的数据包中第一条消息的长度；若缓存中存在缓存数据包，则表示当前数据包是缓存数据包包含的内容的延续，则将当前数据包内容拷贝到缓存数据包之后，进而对不完整的消息进行拼接，拼接后再计算当前缓存的数据包中第一条消息的长度；

步骤101-2)将计算得出的第一条消息的长度和接收的数据包的长度进行比较，针对判决结果的不同情况分别执行如下步骤：

步骤101-2-1)若第一条消息的长度等于接收的数据包长度，表示当前数据包内容恰好为一条完整的消息，则能够对该消息直接进行解析；

步骤101-2-2)若第一条消息的长度小于数据包的长度，则对该数据包进行拆分处理，即从数据包中提取完整的消息，并采用消息首地址和消息长度表征一条完整的消息；

步骤101-2-3)若第一条消息的长度大于数据包的长度，则通过缓存该数据包进而完成若干数据包的拼接，最终得到一条完整的消息，并将得到的完整的消息进行解析。

上述步骤102)具体为：

步骤102-1)根据消息码识别消息类型，进而依据识别的类型判断消息与日志生成是否相关，若消息与生成日志无关，则将其直接舍弃；否则对与生成日志相关的各类型消息分别进行如下处理：

对于版本协商消息，获取消息中的协议版本号并缓存；

对于用户认证请求消息，从消息中提取用户名并缓存；

对于信道请求消息，获取请求的信道类型并缓存；

对于信道中传输的消息，通过消息方向判断属于请求还是响应，并缓存消息方向；其中，若消息方向为从客户端至服务器，则为请求消息，反之为响应消息；

步骤102-2)基于缓存的内容和响应数据包生成解析日志，生成的日志包含：TCP/IP四元组、会话ID、登陆会话的用户名、登陆时间、客户端请求的命令、请求开始时间、服务端返回给客户端的响应数据和响应结束时间；

其中，

所述客户端的请求的命令和服务端返回客户端的响应数据在一个会话的生命期内能够反复发生，而生成的每条解析日志仅包含一条客户端的请求命令和一次服务器端的响应，即不同解析日志的请求和响应相互独立；

在一次会话的生命周期内所述的TCP/IP四元组、会话ID、登陆会话的用户名和登陆时间信息保持不变。

进一步可选的，客户端每次输入都会以消息的形式被送至服务器，并通过服务端返回的回显消息将输入的结果呈现在终端；通过识别回显消息中的转义字符，实现对光标位置的准确控制，结合消息中携带的请求字符复原请求命令，当检测到客户端请求结束时立即将复原的请求命令写入日志缓存中。仅仅将用户请求结束后服务器返回给客户端的数据作为响应数据，将响应数据依次写入日志缓存中，当缓存的日志片段的长度达到设定的发送长度时，立即发送日志片段，对于最后一个日志片段的发送，可由下一次请求驱动，也可由定时器驱动。

此外，本发明还提供了一种基于SSH协议的会话解析系统，所述系统包含：

包处理模块，用于接收基于SSH协议会话的数据包，并对接收的数据包分别进行如下预处理：

当一个数据包包含若干条完整的消息时，从该数据包中依次提取出每一条完整的消息；

当一个数据包所含的消息不完整时，首先将当前数据包包含的不完整的消息进行缓存，然后接收后续的数据包，最后将后续数据包包含的消息和缓存的消息内容进行拼接，直至拼接出一条完整的消息；

解析模块，用于从得到的各条完整的消息中提取与生成日志相关的内容，并按照设定的格式封装与日志相关的内容，进而得到解析日志完成会话解析。

可选的，上述系统还包含：

日志发送模块，用于将生成的解析日志采用流式发送模式发送至日志服务器；其中，所述的流式发送模式为：将生成的解析日志写入日志缓存中，当缓存的日志长度达到设定的发送长度时，立即向日志服务器发送日志。

与现有技术相比，本发明的优势在于：

简化流程——通过对数据包的处理，得到一条条完整的消息，让解析流程变得更简单、更可靠。

节约缓存——对一条完整的消息进行解析，简化处理流程的同时也节约了内存空间；此外，日志传输采用流式发送的方式则大大节约了缓存空间，只需要为每一个解析任务申请一小块缓存空间则可满足日志生成和发送的需求。

附图说明

图1-a是本发明提供的解析系统的各模块的逻辑结构示意图；

图1-b是本发明解析系统的应用场景示意图；

图2是本发明所述方法中包处理模块的处理流程图；

图3是本发明所述方法中响应解析流程图；

图4是本发明所述方法中流式发送的日志片段格式示意图；

具体实施方式

下面结合附图和优选实施例对本发明进行详细说明。

实施例1

为了实现上述方法本发明提供了一种解析系统，所述解析系统如图1-a和1-b所示，图1-a是三个模块的逻辑结构示意图，图1-b是解析系统的应用场景示意图；本发明涉及的三个模块包括：包处理模块、解析模块和日志发送模块。

包处理模块，用于对收到的数据包进行处理，收到的数据包和消息的关系是多对多映射，即有可能一个数据包中包含一条或多条消息，也可能一条消息存在于多个数据包中，若直接对此类数据包进行解析，容易出现消息内容遗漏，造成解析不完整。因此解析前需要先对数据包进行处理，对于包含有多条消息的数据包，从包中依次提取消息，每次提取一条完整的消息，对于包中所含消息不完整时，将不完整的消息进行缓存，待收到后续数据包后，将新到数据和缓存中消息内容进行拼接，直到拼接出一条完整的消息再提交给解析模块进行处理，经过该模块处理后，大大简化了解析模块处理流程，提高了解析效率。

解析模块是所述方法最核心的模块，它负责从一条条完整的SSH消息中识别、分析、提取出与生成日志相关的内容并加以处理，最终生成符合既定格式的解析日志。解析模块的输入是一条完整的SSH消息，消息格式如下：

解析模块拿到消息后首先从payload中获取消息码，消息码是消息类型的唯一标识，通过消息码可以得知当前消息对应SSH协议的哪个阶段，进而对不同阶段的SSH消息做不同的分析和处理，如SSH_MSG_USERAUTH_REQUEST对应于SSH协议的用户认证请求阶段，所述方法对该阶段消息的解析主要在于获取请求认证的用户名。由于包处理模块不对数据包进行识别，因此包处理模块对SSH会话过程中的所有数据包进行处理，解析模块收到的消息必然包含一些与解析过程无关的消息，对于此类消息，解析模块不作任何处理，直接舍弃。

日志发送模块，主要负责将生成的日志发送给日志服务器。传统的方法是等一条日志生成完成后再发送，而该方法中采用流式发送模式传输日志。解析模块边解析边生成日志，生成的日志写入日志缓存中，当缓存的日志长度达到发送长度时，立即将日志发出，不需要等到一条完整的日志生成结束再发送日志，发送模块对日志的监测和及时处理，一定程度上提高了日志传输的效率，同时也大大节省了缓存空间。

可选的，上述包处理模块进一步包含：

第一处理子模块，用于当收到一个基于SSH协议会话的数据包后，首先查看缓存区是否有缓存数据包，若不存在缓存数据包，则直接计算接收的数据包中第一条消息的长度并驱动第二处理子模块；若缓存中存在缓存数据包，则表示当前数据包是缓存数据包包含的内容的延续，则直接驱动第三处理单元；

第二处理子模块，用于将计算得出的第一条消息的长度和接收的数据包的长度进行比较，针对判决结果的不同情况分别启动如下各单元：

第一处理单元，若第一条消息的长度等于接收的数据包长度，表示当前数据包内容恰好为一条完整的消息，则能够对该消息直接进行解析；

第二处理单元，若第一条消息的长度小于数据包的长度，则对该数据包进行拆分处理，即从数据包中提取完整的消息，并采用消息首地址和消息长度表征一条完整的消息；

第三处理单元，若第一条消息的长度大于数据包的长度，则通过缓存该数据包进而完成若干数据包的拼接，最终得到一条完整的消息，再计算完整消息的长度并将得到的完整的消息进行解析。

可选的，上述解析模块进一步包含：

消息过滤子模块，用于根据消息码识别消息类型，进而依据识别的类型判断消息与日志生成是否相关，若消息与生成日志无关，则将其直接舍弃；否则对与生成日志相关的各类型消息分别进行如下处理：

对于版本协商消息，获取消息中的协议版本号并缓存；

对于用户认证请求消息，从消息中提取用户名并缓存；

对于信道请求消息，获取请求的信道类型并缓存；

对于信道中传输的消息，通过消息方向判断属于请求还是响应，并缓存消息方向。其中，若消息方向为从客户端至服务器，则为请求消息，反之为响应消息；

日志生成子模块，用于基于缓存的内容和响应数据包生成解析日志，解析日志包含：TCP/IP四元组、会话ID、登陆会话的用户名、登陆时间、客户端请求的命令、请求开始时间、服务端返回给客户端的响应数据和响应结束时间；

其中，

所述客户端的请求的命令和服务端返回客户端的响应数据在一个会话的生命期内能够反复发生，而生成的每条解析日志仅包含一条客户端的请求命令和一次服务器端的响应，即不同解析日志的请求和响应相互独立；

在一次会话的生命周期内所述的TCP/IP四元组、会话ID、登陆会话的用户名和登陆时间信息保持不变。

进一步可选的，上述日志发送模块进一步包含：

封装子模块，用于发送日志时为其填充日志头，所述日志头包含：“日志编号”、“是否分段”、“分段号”和“最后一段”；其中，“日志编号”，用于表征一条唯一的日志；“是否分段”，用于标记本条日志是否被分段发送，此标识为0表示本段内容即为整条日志内容，否则，日志被分为若干段；“分段号”和“最后一段”在“是否分段”标识为1时才有意义，“分段号”是日志片段的唯一标识；和

发送子模块，用于将封装后的日志发送至存储服务器；

其中，存储服务器收到日志片段后将具有相同“日志编号”的日志片段按“分段号”从小到大依次拼接便进而拼凑出一条完整的日志。

实施例2

本发明为了满足某些企业或机构对业务审计的需求，提出了一种基于SSH协议的会话解析方法。

本发明提供的一种基于SSH协议的会话解析方法包含以下步骤，所述方法处理的是明文SSH数据包：

每到达一个SSH数据包后，将其提交给包处理模块。处理前的数据包中可能包含一条不完整的消息，也可能包含一条完整的消息，还可能包含多条消息，包处理模块通过对数据包的拆分和拼接，生成一条完整的消息，供协议解析模块解析。

其中，包拆分的过程实际是从包中提取消息的过程，用消息首地址和消息长度表征一条消息；而包拼接的过程则是通过缓存数据包实现的，提交给包处理模块的是经过重组的数据包，能保障SSH报文的时序，这保证了拼接后的消息的完整性和消息内容的正确性。

协议解析模块根据消息码识别消息类型，不同的消息类型对应SSH会话的不同阶段，解析模块识别出该消息与日志生成有关，则对消息头进行解析，若该消息与生成日志无关，则将其直接舍弃。

其中，对不同类型的消息解析的方法不同，对于版本协商消息，直接将消息缓存；对于用户认证请求消息，从消息中提取用户名并缓存，对于信道请求消息，获取请求的信道类型，确保该信道用于SSH会话，对于信道中传输的消息，通过消息方向判断属于请求还是响应，若消息方向为C→S，则为请求消息，反之消息方向为S→C则为响应消息。对不同类型的消息进行解析，并缓存相关内容以生成解析日志。

该方法生成的日志包括TCP/IP四元组、会话ID、登陆会话的用户名、登陆时间等信息，一条会话的生命期内，只会发生一次版本协商和用户认证过程，解析时维护的TCP/IP四元组、会话ID、登陆会话的用户名、登陆时间等信息在一次会话生命期内不会改变。

生成的日志还包括客户端请求的命令、请求开始时间、服务端返回给客户端的响应数据和响应结束时间，不同于登陆信息，客户端的请求和服务端的响应在一个会话的生命期内可以反复发生，该方法限定每条日志中包含且仅包含一条请求和一条响应，所以同一会话的不同日志共用TCP/IP四元组、会话ID、登录会话的用户名、登陆时间等信息，不同日志的请求和响应则是相互独立的。

解析过程中边生成日志边缓存，日志传输采用流式发送的方式，即当缓存的日志长度达到发送长度时便将日志发送到指定的存储服务器，不需要等一条日志全部生成完成才发送。

图2是包处理模块的处理流程图，包含以下步骤：

a)包处理模块收到一个数据包后，首先查看缓存区是否有缓存数据包，若不存在缓存数据包，则直接计算数据包中第一条消息的长度；若存在缓存数据包，则表示当前数据包是缓存数据包内容的延续，将当前数据包内容拷贝到缓存数据包之后，对不完整的消息进行拼接，拼接后再计算当前缓存的数据包中第一条消息的长度；

b)将计算出的第一条消息长度和数据包长度进行比较，根据比较结果执行c)、d)、e)步骤；

c)若消息长度等于数据包长度，表示当前数据包内容恰好为一条完整的消息，直接将消息提交给解析模块进行解析；

d)若消息长度小于数据包长度，表示当前数据包不止包含一条完整的消息，从数据包中取出第一条完整的消息，提交给解析模块进行解析，再计算剩余数据包中第一条消息的长度，重复b)步骤；

e)若消息长度大于数据包长度，表示当前数据包所含内容仅为一条消息的一部分，不完整的消息则不能提交给解析模块，若当前数据包尚未缓存，则缓存该数据包，若当前数据包已在缓存区中则将数据包内容移动缓存区头，以便为后续待缓存数据包腾出内存空间。

解析时需要记录用户输入的完整请求，而用户输入可能借助各种快捷键或功能键，要复原用户的请求，需识别并能理解服务端返回给客户端的回显消息，而理解回显消息的关键在于识别回显消息中的转义字符。

表1是本发明所述方法的回显消息中的转义字符集

操作	字符	功能
			回车	0d	将光标移至行首
左移	08	光标向左移一位
			右移	1b 5b 43	光标向右移一位
删除至行尾	1b 5b 4b	删除当前光标至行尾的字符
			插入字符	1b 5b Pn 40	在当前光标出插入Pn个空字符
删除字符	1b 5b Pn 50	从当前光标开始向后删除Pn个字符

客户端每次输入请求都会收到来自服务端的回显消息，回显消息中除了包含客户端输入的字符，还包括转义字符，如表1所示，通过对转义字符的解析可准确定位任意时刻光标的位置和当前请求内容，从而可实现对任意请求内容的完整复原。

图3是响应解析流程图，包含以下步骤：

1)解析模块收到一个S→C的消息，判断请求状态是否为“完成”。；

2)若请求状态为“完成”，表示当前消息为响应消息，响应消息均以‘\r\n’开头，收到‘\r\n’消息时，将响应状态置为“READY”。所述方法对响应的处理是当响应状态为“READY”时将所有响应消息内容直接写入缓存日志中。

3)向日志缓存中写入响应内容时，判断当前缓存日志的长度，若缓存日志长度已达日志发送长度，则立即发送日志。

4)将下一次请求达到作为上一次响应结束的标识，此时不管缓存日志长度多少，在缓存日志尾部加上响应结束时间和日志结束标记，并立即发送日志。若下一次请求迟迟未到，则上一次解析生成的最后一段日志需要通过定时器触发其发送，定时器触发日志发送模块对日志状态进行监测，若日志状态相对于前一个定时周期已无任何变化，则表明已生成整条日志，应立即发送当前缓存的日志片段。

因为采用流式发送方式传输日志，所以每次发送的内容仅为整条日志的一小段，为了保证日志内容的完整性和正确性，为每个日志片段加上日志头，日志头格式如图4虚线框中所示。其中，“日志编号”用于表征一条唯一的日志；“是否分段”用于标记本段日志是否被分段发送，此标识为0表示本段内容即为整条日志内容，否则，日志被分为若干段；“分段号”和“最后一段”在“是否分段”标识为1时才有意义，“分段号”是日志片段的唯一标识，存储服务器收到日志片段后将具有相同“日志编号”的日志片段按“分段号”从小到大依次拼接便能拼凑出一条完整的日志。

采用上述技术方案得到的日志如表2所示。

表2是本发明所述方法定制的日志格式

数据内容	数据类型	序号
			源端口	Ushort	1
目的端口	Ushort	2
			源IP	IPv4	3
服务器IP	IPv4	4
			数据ID	String	5
会话ID	String	6
			UUID	String	7
数据详细类型	Ulong	8
			服务器版本	String	9
登陆时间	Time	10
			登陆名称	String	11
数据操作开始时间	Time	12
			操作命令	String	13
返回数据	String	14
			数据操作结束时间	Time	15

综上所述，本发明提出了一种基于SSH协议的会话解析方法，所述方法涉及三个模块：包处理模块、解析模块和日志发送模块。(1)包处理模块将到达的数据包进行拆分和拼接，得到一条条完整的消息并提交给解析模块；(2)解析模块通过消息码区分消息类型，从不同类型的消息中提取不同内容，再将提取出的内容处理后写入日志中，每条日志包含且仅包含一次请求和一次响应；(3)日志发送模块负责监测日志状态，并采用流式发送的方式传输日志，即当本地缓存的日志长度达到发送长度时，日志发送模块立即将日志发送给存储服务器，不用等日志生成完成才发送，从而节约了缓存空间。本发明的技术能实现基于SSH会话的审计，可以为诸如银行等机构提供安全保障。

最后所应说明的是，以上实施例仅用以说明本发明的技术方案而非限制。尽管参照实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，对本发明的技术方案进行修改或者等同替换，都不脱离本发明技术方案的精神和范围，其均应涵盖在本发明的权利要求范围当中。

Claims (10)

1.一种基于SSH协议的会话解析方法，所述方法包含：

步骤101)接收基于SSH协议会话的数据包，并对接收的数据包分别进行如下预处理：

当一个数据包包含若干条完整的消息时，从该数据包中依次提取出每一条完整的消息；

当一个数据包所含的消息不完整时，首先将当前数据包包含的不完整的消息进行缓存，然后接收后续的数据包，最后将后续数据包包含的消息和缓存的消息内容进行拼接，直至拼接出一条完整的消息；

步骤102)从得到的各条完整的消息中提取与生成日志相关的内容，并按照设定的格式封装与日志相关的内容，进而得到解析日志完成会话解析。

2.根据权利要求1所述的基于SSH协议的会话解析方法，其特征在于，所述步骤102)之后还包含：

步骤103)将生成的解析日志采用流式发送模式发送至日志服务器；

其中，所述的流式发送模式为：将生成的解析日志写入日志缓存中，当缓存的日志长度达到设定的发送长度时，立即向日志服务器发送解析日志信息。

3.根据权利要求1所述的基于SSH协议的会话解析方法，其特征在于，所述步骤101)进一步包含：

步骤101-1)当收到一个基于SSH协议会话的数据包后，首先查看缓存区是否有缓存数据包，若不存在缓存数据包，则直接计算接收的数据包中第一条消息的长度；若缓存中存在缓存数据包，则表示当前数据包是缓存数据包包含的内容的延续，则将当前数据包内容拷贝到缓存数据包之后，进而对不完整的消息进行拼接，拼接后再计算当前缓存的数据包中第一条消息的长度；

步骤101-2)将计算得出的第一条消息的长度和接收的数据包的长度进行比较，针对判决结果的不同情况分别执行如下步骤：

步骤101-2-1)若第一条消息的长度等于接收的数据包长度，表示当前数据包内容恰好为一条完整的消息，则能够对该消息直接进行解析；

步骤101-2-2)若第一条消息的长度小于数据包的长度，则对该数据包进行拆分处理，即从数据包中提取完整的消息，并采用消息首地址和消息长度表征一条完整的消息；

步骤101-2-3)若第一条消息的长度大于数据包的长度，则通过缓存该数据包进而完成若干数据包的拼接，最终得到一条完整的消息，并将得到的完整的消息进行解析。

4.根据权利要求1所述的基于SSH协议的会话解析方法，其特征在于，所述步骤102)具体为：

步骤102-1)根据消息码识别消息类型，进而依据识别的类型判断消息与日志生成是否相关，若消息与生成日志无关，则将其直接舍弃；否则对与生成日志相关的各类型消息分别进行如下处理：

对于版本协商消息，获取消息中的协议版本号并缓存；

对于用户认证请求消息，从消息中提取用户名并缓存；

对于信道请求消息，获取请求的信道类型并缓存；

对于信道中传输的消息，通过消息方向判断属于请求还是响应，并缓存消息方向；其中，若消息方向为从客户端至服务器，则为请求消息，反之为响应消息；

步骤102-2)基于缓存的内容和响应数据包生成解析日志，生成的日志包含：TCP/IP四元组、会话ID、登陆会话的用户名、登陆时间、客户端请求的命令、请求开始时间、服务端返回给客户端的响应数据和响应结束时间；

其中，

所述客户端的请求的命令和服务端返回客户端的响应数据在一个会话的生命期内能够反复发生，而生成的每条解析日志仅包含一条客户端的请求命令和一次服务器端的响应，即不同解析日志的请求和响应相互独立；

在一次会话的生命周期内所述的TCP/IP四元组、会话ID、登陆会话的用户名和登陆时间信息保持不变。

5.根据权利要求4所述的基于SSH协议的会话解析方法，其特征在于，客户端每次输入都会以消息的形式被送至服务器，并通过服务端返回的回显消息将输入的结果呈现在终端；通过识别回显消息中的转义字符，实现对光标位置的准确控制，结合消息中携带的请求字符复原请求命令，当检测到客户端请求结束时立即将复原的请求命令写入日志缓存中。

6.一种基于SSH协议的会话解析系统，其特征在于，所述系统包含：

包处理模块，用于接收基于SSH协议会话的数据包，并对接收的数据包分别进行如下预处理：

当一个数据包包含若干条完整的消息时，从该数据包中依次提取出每一条完整的消息；

当一个数据包所含的消息不完整时，首先将当前数据包包含的不完整的消息进行缓存，然后接收后续的数据包，最后将后续数据包包含的消息和缓存的消息内容进行拼接，直至拼接出一条完整的消息；

解析模块，用于从得到的各条完整的消息中提取与生成日志相关的内容，并按照设定的格式封装与日志相关的内容，进而得到解析日志完成会话解析。

7.根据权利要求6所述的基于SSH协议的会话解析系统，其特征在于，所述系统还包含：

日志发送模块，用于将生成的解析日志采用流式发送模式发送至日志服务器；其中，所述的流式发送模式为：将生成的解析日志写入日志缓存中，当缓存的日志长度达到设定的发送长度时，立即向日志服务器发送日志。

8.根据权利要求7所述的基于SSH协议的会话解析系统，其特征在于，所述包处理模块进一步包含：

第一处理子模块，用于当收到一个基于SSH协议会话的数据包后，首先查看缓存区是否有缓存数据包，若不存在缓存数据包，则直接计算接收的数据包中第一条消息的长度并驱动第二处理子模块；若缓存中存在缓存数据包，则表示当前数据包是缓存数据包包含的内容的延续，则直接驱动第三处理单元；

第二处理子模块，用于将计算得出的第一条消息的长度和接收的数据包的长度进行比较，针对判决结果的不同情况分别启动如下各单元：

第一处理单元，若第一条消息的长度等于接收的数据包长度，表示当前数据包内容恰好为一条完整的消息，则能够对该消息直接进行解析；

第二处理单元，若第一条消息的长度小于数据包的长度，则对该数据包进行拆分处理，即从数据包中提取完整的消息，并采用消息首地址和消息长度表征一条完整的消息；

第三处理单元，若第一条消息的长度大于数据包的长度，则通过缓存该数据包进而完成若干数据包的拼接，最终得到一条完整的消息，再计算完整消息的长度并将得到的完整的消息进行解析。

9.根据权利要求7所述的基于SSH协议的会话解析系统，其特征在于，所述解析模块进一步包含：

消息过滤子模块，用于根据消息码识别消息类型，进而依据识别的类型判断消息与日志生成是否相关，若消息与生成日志无关，则将其直接舍弃；否则对与生成日志相关的各类型消息分别进行如下处理：

对于版本协商消息，获取消息中的协议版本号并缓存；

对于用户认证请求消息，从消息中提取用户名并缓存；

对于信道请求消息，获取请求的信道类型并缓存；

对于信道中传输的消息，通过消息方向判断属于请求还是响应，并缓存消息方向。其中，若消息方向为从客户端至服务器，则为请求消息，反之为响应消息；

日志生成子模块，用于基于缓存的内容和响应数据包生成解析日志，解析日志包含：TCP/IP四元组、会话ID、登陆会话的用户名、登陆时间、客户端请求的命令、请求开始时间、服务端返回给客户端的响应数据和响应结束时间；

其中，

所述客户端的请求的命令和服务端返回客户端的响应数据在一个会话的生命期内能够反复发生，而生成的每条解析日志仅包含一条客户端的请求命令和一次服务器端的响应，即不同解析日志的请求和响应相互独立；

在一次会话的生命周期内所述的TCP/IP四元组、会话ID、登陆会话的用户名和登陆时间信息保持不变。

10.根据权利要求7所述的基于SSH协议的会话解析系统，其特征在于，所述日志发送模块进一步包含：

封装子模块，用于发送日志时为其填充日志头，所述日志头包含：“日志编号”、“是否分段”、“分段号”和“最后一段”；其中，“日志编号”，用于表征一条唯一的日志；“是否分段”，用于标记本条日志是否被分段发送，此标识为0表示本段内容即为整条日志内容，否则，日志被分为若干段；“分段号”和“最后一段”在“是否分段”标识为1时才有意义，“分段号”是日志片段的唯一标识；和

发送子模块，用于将封装后的日志发送至存储服务器；

其中，存储服务器收到日志片段后将具有相同“日志编号”的日志片段按“分段号”从小到大依次拼接便进而拼凑出一条完整的日志。