CN110719255A - 基于ssh协议的协同运维方法与系统 - Google Patents

Abstract

本发明公开了一种基于SSH协议的协同运维方法与系统，包括:第一运维端与目标设备建立连接；向第二运维端发送协助请求；第二运维端接受协助请求后，与第一运维端之间建立数据通道；所述两个运维端的输入和响应，经所述数据通道,在对端进行同步显示。通过发起运维协助请求，使得两个以上运维人员能同时进行运维操作，并且同步显示所有的输入和响应信息，从而实现了高效、准确的协同运维。技术方案包括协同运维方法与系统。

Description

基于SSH协议的协同运维方法与系统

技术领域

本发明属于计算机与网络信息安全技术领域，尤其涉及一种利用SSH协议实现协同运维的方法及应用该方法的系统。

背景技术

随着计算机信息技术的深入应用，大中型企业和机构庞大而复杂的IT系统，由于变更设计不完善、误操作、越权操作、恶意操作及代维等因素，系统的运营、维护和管理的风险不断加大。安全运维管理系统（也称堡垒机）是一种可对主机、服务器、网络设备、安全设备等的管理维护进行操作审计的网络安设备，可以实现对策略配置、系统维护、内部访问等进行详细的记录；对不同的运维用户和终端进行运维协议、目标主机、运维时间段、运维会话时长、运维客户端IP等组合的授权，运维用户只能看见和执行已授权的操作，非授权的运维用户无法跳转至其他IT设备。

安全运维管理系统在现实中存在这样一种情况，对于业务不熟悉的运维人员，或者是需要进行高级技术支持时，往往需要请求更熟悉业务或更高级的技术人员提供协助，从而帮助用户快速的解决问题，提高运维效率，但是目前多是通过电话沟通进行协助运维，效率较低；特别是对目标设备进行底层的专业操作时，需要利用专业的工具进行连接以及输入代码命令，常规的远程协助技术无法实现高效、准确的运维操作。

发明内容

有鉴于此，提供一种基于SSH协议的协同运维方法与系统，通过发起运维协助请求，使得两个以上运维人员能同时进行运维操作，并且同步显示所有的输入和响应信息，从而实现了高效、准确的协同运维。技术方案包括协同运维方法与系统。

基于SSH协议的协同运维方法，包括:

第一运维端与目标设备建立连接；

向第二运维端发送协助请求；

第二运维端接受协助请求后，与第一运维端之间建立数据通道；

所述两个运维端的输入和响应，经所述数据通道,在对端进行同步显示。

具体的：所述第一运维端:发送协助请求时，为当前运维进程创建包括运维规则的临时运维资源；将当前运维的用户名、目标设备IP与进程ID存入运维平台的共享内存，并创建本地socket套接字；

第二运维端: 通过所述临时运维资源连接至第一运维端的对应运维进程；读取所述共享内存信息，创建本地socket套接字，与第一运维端建立数据通道。

运维端收到对端的写描述符时，将本端的写描述符发送给对端。

第一运维端的命令输入，写入本地写描述符中，输入和响应信息通过数据通道发送至第二运维端进行显示；

第二运维端的命令输入，写入第一运维端的写描述符中，输入和响应信息在第一运维端进行显示并通过数据通道发送至第二运维端进行显示；

所述第一运维端的写描述符将命令通过运维平台发送至目标设备进行执行。

优选的，两个运维端同时输入的命令，根据第一运维端的写描述符接收到命令的先后顺序显示输入和响应信息。

优选的，第二运维端拒绝协助请求时，或超过预设时长未接受协助请求时，或中断协同运维时，或终止协同运维时：第一运维端销毁所述临时运维资源；第一运维端中断或终止协同运维时，同时结束第二运维端的运维进程，并销毁临时运维资源；所述临时运维资源销毁后,第一运维端可继续对目标设备的运维；对于第一运维端进行的其他运维进程，第二运维端无法连接。

优选的，第一运维端可选择并向至少1个第二运维端发送协助请求；所述第二运维端为在线的运维端。

所述运维端通过Web浏览器或VPN客户端进行协同运维。

基于SSH协议的协同运维系统，包括：

运维平台，基于SSH协议，通过获取和加载运维配置和规则，记录和审计运维操作、保存运维日志和告警，并实现日志查询和回放；

请求端，对目标设备进行运维，并向协助端发送协助请求；

协助端，接受请求端的协助请求，通过运维平台与请求端建立数据通道，实现协同运维。

优选的，系统应用于Linux目标设备的运维，包括数据库或应用服务器、路由器、交换机；所述请求端与协助端利用内嵌的连接工具通过运维平台连接到目标设备，所述连接工具包括xshell、putty、secureCRT。

上述的技术方案，请求端通过运维平台使用ssh运维工具连接到需要运维的目标设备上，然后向协助端发起协助请求，协助端收到协助请求后，进入了与请求端同步显示的运维界面，此时请求端与协助端可以同时看到各自所有的输入和响应信息，不仅运维过程直观明了，对于对方的不当操作，也可以及时的进行退回，避免了问题操作；而且每次的协同运维是针对单一设备按照同样的运维规则进行，不涉及运维权限问题。整个方案对于快速定位用户的设备问题、提高运维效率有积极意义。

附图说明

图1为基于SSH协议的协同运维方法实施例的运维端交互基本流程图；

图2为图1中运维端之间数据通道的建立流程示意图；

图3为图1中运维端协同运维的同步显示示意图；

图4为基于SSH协议的协同运维系统实施例的组成框图。

具体实施方式

首先对SSH协议相关内容进行简要说明。

传统的ftp、pop和telnet等网络服务协议在本质上都是不安全的，因为它们在网络上用明文传送口令和数据，容易被截获；而且，这些服务程序的安全验证方式也有其弱点，容易受到“中间人”（man-in-the-middle）这种方式的攻击。所谓“中间人”的攻击方式，就是“中间人”冒充真正的服务器接收用户的数据，然后再冒充用户把数据传给真正的服务器。使用SSH，可以把所有传输的数据进行加密，这样可以防止数据被截获，也可以防止DNS欺骗和IP欺骗；而且SSH传输的数据是经过压缩的，所以可以加快传输的速度；SSH有很多功能，它既可以代替Telnet，又可以为FTP、PoP、甚至为PPP提供一个安全的"通道"。

其次对运维平台（安全运维管理系统，也称堡垒机）的原理进行简要说明。

运维人员登录进入运维平台的用户系统，便可以查看到当前用户有权运维的所有运维资源，运维资源的内容包括设备名称、设备IP、运维规则、访问协议以及可进行的操作。当运维资源的访问协议为SSH时，可以通过内嵌的连接工具去连接待运维的目标设备，连接成功后可以在连接工具的界面登录到设备，开始运维。不同运维人员（用户名）有权运维的资源不同，因此当前运维人员无法解决问题时，就需要进行协助请求。

下面就结合附图和实施例对基于SSH协议的协同运维方法与系统的技术方案进行详细说明。

首先是一种协同运维方法，如图1所示，主要的交互过程包括：

S10.第一运维端与目标设备建立连接；

S20.向第二运维端发送协助请求；

S30.第二运维端接受协助请求后，与第一运维端之间建立数据通道；

S40.所述两个运维端的输入和响应，经所述数据通道,在对端进行同步显示。

如图2所示，对图1的各个步骤进行展开叙述。

第一运维端执行步骤S11以及S20至S25：

步骤S11：如前所述，第一运维端的运维资源列表内，显示当前用户有权运维的目标设备，如果该目标设备的访问协议是SSH，则可以选择相应的连接工具连接到目标设备；因为运维资源是事先在运维平台进行配置的，如果配置时已设置了用户名与密码，那么连接工具打开时会自动填入，运维平台认证通过后，即与目标设备连接成功，运维人员可以通过在连接工具界面输入命令与目标设备进行通信。

步骤S20：在对目标设备的运维中，如需要其他运维人员进行协助，则需要发送协助请求；发送协助请求的对象（即第二运维端）可以由第一运维端通过对应的用户名进行选择，为了便于快速响应协助请求，此处可被选择的用户名优选的为当前已登录运维平台用户系统并在线的运维人员。

步骤S21：选定用户名并向该对应的第二运维端发送协助请求后，其请求被发送至第二运维端；

步骤S22：协助请求的内容包括第一运维端根据当前正在运维的资源复制并创建的临时运维资源；

步骤S23、S24：发送协助请求的同时，将当前运维进程对应的用户名、目标IP、进程ID存入运维平台的共享内存中供第二运维端获取，并通过创建本地套接字文件，监听来自第二运维端发送的写描述符。

第二运维端执行步骤S31至S34：

步骤S31：如步骤S20所述，被请求的第二运维端为在线运维用户，因此协助请求到达该用户时进行必要的提示，该提示可以是在该运维人员的用户系统中增加了一条拷贝自第一运维端的临时运维资源，该临时运维资源具有同意和拒绝协助的选择；

步骤S32：如果第二运维端同意协助请求，通过该临时运维资源与第一运维端的需要被协助的运维进程建立连接；

步骤S33：第二运维端通过访问第一运维端存入运维平台共享内存的信息，创建对应的本地套接字文件；同时监听来自第一运维端发送的写描述符。

步骤S34：第二运维端将本端的写描述符发送给第一运维端；

步骤S25：第一运维端的第一监听进程收到后将本端的写描述符发送给第二运维端，至此，第一运维端与第二运维端通过各自的本地套接字建立了数据通道，第二运维端打开相应连接工具的运维界面。

如图3所示，第一运维端与第二运维端之间实现同步显示的过程：

第一运维端的命令输入，写入本地写描述符中，输入和响应信息通过数据通道发送至第二运维端进行显示；

第二运维端的命令输入，写入第一运维端的写描述符中，输入和响应信息在第一运维端进行显示并通过数据通道发送至第二运维端进行显示；

如上所述，第二运维端的输入操作，直接写入对端的写描述符中，而屏蔽对本端写描述符的操作，即两个运维端的输入均是通过第一运维端的写描述符发送到目标设备进行执行。

作为优选的实施方式，当第二运维端拒绝协助请求时，或超过预设时长未接受协助请求时，或中断协助运维时，或终止协助运维时：第一运维端销毁所述临时运维资源；

第一运维端中断或终止协同运维时，同时结束第二运维端的运维进程，并销毁临时运维资源；

所述临时运维资源销毁后,第一运维端可继续对目标设备的运维；对于第一运维端进行的其他运维进程，第二运维端无法连接。

如图4所示，基于SSH协议的协同运维系统，包括：

运维平台，基于SSH协议，通过获取和加载运维配置和规则，记录和审计运维操作、保存运维日志和告警，并实现日志查询和回放；

请求端，对目标设备进行运维，并向协助端发送协助请求；

协助端，接受请求端的协助请求，通过运维平台与请求端建立数据通道，实现协同运维。

优选的，系统应用于Linux目标设备的运维，包括数据库或应用服务器、路由器、交换机；所述请求端与协助端利用内嵌的连接工具通过运维平台连接到目标设备，所述连接工具包括xshell、putty、secureCRT。

具体的：

请求端和协助端可以通过Web浏览器或VPN客户端登录运维平台的用户系统，运维端通过选择内置的xshell、putty、secureCRT等连接工具连接目标设备。

运维平台主要包括:openssh模块，文本类运维核心代理模块，主要实现ssh协议和telnet协议的运维；sysapp模块，主要用于存放运维配置和规则，供代理模块进行获取；proxy_monitor模块，用于记录事件日志和告警，供日志查询和实时监控；实时监控模块，主要通过读取proxy_monitor记录数据，进行实时回放。

以A为请求端，B为协助端为例进行举例说明。

请求端A通过登录到运维平台的用户系统后，选择运维协议进入到相应的运维资源列表，登录运维资源成功后进入连接工具的运维界面，该运维资源在资源列表中的状态变为正在运维，同时该资源操作栏会出现邀请按钮；点击该邀请按钮后选择欲求助的用户名并发出请求，也可以通过模糊搜索选择用户名，之前的邀请按钮变为了取消按钮，可以点击终端请求并重新进行前述过程。

协助端B会进行消息提示，当协助端B点击提示中的链接直接进入到协助端B的运维资源列表界面，其资源列表中会出现一条新的协同运维资源，该资源为临时运维资源并具有接受邀请与拒绝邀请按钮；协助端B可选择接受邀请或拒绝邀请。

当协助端B接受邀请后，就自动连接进入到运维目标设备的界面中，开始协同运维，请求端A使用预设的运维规则进行运维，协助端B使用临时运维资源对同一目标运维设备进行运维，临时运维资源中具有拷贝自请求端A的相同运维规则；

请求端A与协助端B在各自运维界面的命令输入以及响应，都会通过两者之间的数据通道传输到对端的界面进行同步显示；当协同运维结束后，销毁协助端B的临时运维资源及其拷贝的运维规则。

应当说明的是，协助端B收到协助请求之前，请求端A已经通过内嵌的连接工具连接上目标设备，同时请求端A为协助端B拷贝一份临时运维资源及运维规则，用于协助端B对请求端A的运维进程进行访问协助；该临时运维资源依赖于请求端A主运维资源的在线情况，若主资源离线，该临时资源随之离线；运维结束后，主资源将此临时资源销毁，协助端B不能继续访问该资源；

请求端A和协助端B都具有写输入操作权限，协助端B的输入不会直接传输到目标设备去执行，而是由请求端A传输至目标设备进行实际执行；

协助端B接受协助请求后，请求端A再次连接和运维的其他目标设备不参与本次协同运维。

可见，上述的基于SSH协议的协同运维方法与系统，通过两个以上运维端同时进行运维操作，且同步显示输入和响应信息，并且每次协同运维只针对单一目标设备在有限时间内按照同一运维规则进行，该次运维结束则协助端无法独立连接到被运维的目标设备，不会影响到运维权限及规则，既有利于提高运维工作效率，又可以保证各个运维端的独立性和安全性。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.基于SSH协议的协同运维方法,其特征在于,包括:

第一运维端与目标设备建立连接；

向第二运维端发送协助请求；

第二运维端接受协助请求后，与第一运维端之间建立数据通道；

所述两个运维端的输入和响应，经所述数据通道,在对端进行同步显示。

2.根据权利要求1所述的协同运维方法，其特征在于，

所述第一运维端:发送协助请求时，为当前运维进程创建包括运维规则的临时运维资源；将当前运维的用户名、目标设备IP与进程ID存入运维平台的共享内存，并创建本地socket套接字；

第二运维端: 通过所述临时运维资源连接至第一运维端的对应运维进程；读取所述共享内存信息，创建本地socket套接字，与第一运维端建立数据通道。

3.根据权利要求2所述的协同运维方法，其特征在于，运维端收到对端的写描述符时，将本端的写描述符发送给对端。

4.根据权利要求3所述的协同运维方法，其特征在于：

第一运维端的命令输入，写入本地写描述符中，输入和响应信息通过数据通道发送至第二运维端进行显示；

第二运维端的命令输入，写入第一运维端的写描述符中，输入和响应信息在第一运维端进行显示并通过数据通道发送至第二运维端进行显示；

所述第一运维端的写描述符将命令通过运维平台发送至目标设备进行执行。

5.根据权利要求4所述的协同运维方法，其特征在于，两个运维端同时输入的命令，根据第一运维端的写描述符接收到命令的先后顺序显示输入和响应信息。

6.根据权利要求2所述的协同运维方法，其特征在于，

第二运维端拒绝协助请求时，或超过预设时长未接受协助请求时，或中断协同运维时，或终止协同运维时：第一运维端销毁所述临时运维资源；

第一运维端中断或终止协同运维时，同时结束第二运维端的运维进程，并销毁临时运维资源；

所述临时运维资源销毁后,第一运维端可继续对目标设备的运维；

对于第一运维端进行的其他运维进程，第二运维端无法连接。

7.根据权利要求1所述的协同运维方法，其特征在于，第一运维端可选择并向至少1个第二运维端发送协助请求；所述第二运维端为在线的运维端。

8.根据权利要求1所述的协同运维方法，其特征在于，所述运维端通过Web浏览器或VPN客户端进行协同运维。

9.基于SSH协议的协同运维系统，其特征在于，包括：

运维平台，基于SSH协议，通过获取和加载运维配置和规则，记录和审计运维操作、保存运维日志和告警，并实现日志查询和回放；

请求端，对目标设备进行运维，并向协助端发送协助请求；

协助端，接受请求端的协助请求，通过运维平台与请求端建立数据通道，实现协同运维。

10.根据权利要求9所述的协同运维系统，其特征在于，系统应用于Linux目标设备的运维，包括数据库或应用服务器、路由器、交换机；所述请求端与协助端利用内嵌的连接工具通过运维平台连接到目标设备，所述连接工具包括xshell、putty、secureCRT。

Images