Open xueqino1 opened 2 years ago
客户端在向服务器端创建连接时会发送握手报文其中包含密钥信息,这样做的目的是为了确保客户端是一个可信任的客户端,如果设置为不一样的则无法达到以上目的。
但是如果被控端和主控端密码一致,主控端的密码就泄露了,任何一个被控端都可以运行主控端程序操作其他被控端了。
其实这是一个授权问题,后期可以加入授权密码来确保你只能控制被允许访问的设备,而secret的设计是为了确保只有可信任的客户端才能连接到服务器端,而不是所有客户端都可连接。
natpass的设计初衷是为了解决远程办公问题,因此大多数的使用场景是服务器端被部署在外网环境底下用于流量转发,而非内网环境下的多台设备间的互访,因此secret的设计是有必要的。另外我正在构思堡垒机的工作模式,来减少需要部署的设备数量,在该项目中可能会引入一些授权机制,请关注bunker项目
我可能没表达清楚我的意思,您说的“secret的设计是为了确保只有可信任的客户端才能连接到服务器端”这些我都理解,可能您设计的初衷,主控端和被控端,都是当作“客户端”。我的用法比较特别,是类似于teamviewer那种,希望被控端只能用分配给自己的id和密码连接服务器,主控端对连接到服务器的所有被控端都有管理权限。
设计理念上其实是有些出入的,teamviewer包括todesk等因为是SaaS化的服务他的客户端都是连接到他自身服务器上,而natpass的优势是可以私有化部署,所以在使用过程中所有客户端的ID希望交给客户自己管理,因此在使用过程中你不光需要知道服务端的地址还需要知道被连接的节点ID,因此设置一个随机的客户端ID可以在某种程度上实现类似于teamviewer中服务端分配id的功能。
你所需要的功能其实本质上还是授权方面的功能,因为客户端id是随机生成的,因此你可以猜到我的客户端id,为了保证你可以连接到我这个节点我还需要把连接到我的密码给你,这个功能的最终目的就是我授权给你来访问我这个节点。
另外为了使natpass足够轻量化,我并没有为其设计诸如jumpserver的3A认证相关的功能,natpass的主要目标是为了实现远程/异地办公,远程桌面和远程shell只是其中的一小部分功能,后期还会接入更多的web应用。
关于授权其实还有另外一部分,比如某个节点允许你连shell但不允许你连远程桌面等,这些都是3A认证需要实现的功能,这些功能将会在bunker项目中得以实现。
谢谢回复解答!
现在预共享密钥,主控端和被控端,都必须和服务器的保持一致是吗?是否可以支持分别设定密码呢?