@Volekingsg 感谢回复,MX 指 MobaXterm

现在堡垒机启动的时候都是直接 web 页面唤起 xshell 或者是 MobaXterm,然后如果唤起的是 xshell,则可以在 "转移规则"处右键新建一个隧道,但是实际测试发现看似建立成功但是无法正常工作
而如果唤起的是 MobaXterm,也有一个新建隧道的能力(也就是图 1),但是他要求填这个堡垒机或者目标机器的密码,实际情况是我无法知道堡垒机或者目标机器的 ssh 用户名和密码
现在也无法控制堡垒机给出其他连接方案,比如楼上说的开放 token 连接,他 web 唤起的程序用到的用户名密码都是随机的,而且一旦唤起的程序连接之后,在用相同用户名密码就无法建立独立的 ssh 连接(xshell 中的"赋值渠道"是可以,但是隧道仍然不行)

如果能通过稳定的用户名密码连接到远程 ssh,这个情况我测试过,隧道的确正常

@dwlovelife #113 我意思是我们周边脂肪肝的多🤣

我们这已经从违停 100 改回 200 了😅

@morenacl 感谢建议,不得行,我对堡垒机没有控制权,别人只给了这种方式😁

久坐不是更多的脂肪肝吗🤣

刚测试了一下把 web 上启动的 xshell 临时会话另存为标准会话后,解密了会话中的用户名密码
在会话不断开的情况下,使用其他 ssh 客户端使用账号密码去连接堡垒机,会发现无法连接,提示密码错误
换句话说,这个密码应该是一次性密码,用一次就失效

不是很确定 ssh 隧道是否是单独启动独立的 ssh 会话去建立隧道,如果是的话那肯定就不行,因为密码已经失效了

之前遇到过访问某 fq 官网被劫持,换到 1111 才正常

@liuzimin 我们路由器直接不支持 ipv6😂

@kumiko 税点吗?我感觉除了公户的年费没有其他费用了

@Tacks 是的,解决方案我们也是这样处理.只是好奇为啥不一致,我意思他排序算法跨平台不稳定而且不可配置好像

现在我们没有特别在意字段和关键字重复的情况,因为大部分时候都是 orm 自动生成的标准 sql,不会造成错误或者冲突

后端部分,.net 应该可控性要大于 nodejs,对于后期拓展应该更为容易,比如对接硬件,此外,虽然.net 后端在 web 侧赶不上 java,但是超过 nodejs 也许没太大问题
前端部分,nodejs 只在其中起一个工程作用,运行时几乎没有关系

@RHG #29 我用之前 vmware 账号无法登录,所以只能重新注册一个新的

@RHG 你这是输入长度不足没通过校验把

🤣

softether 挺好,也简单

https://www.tagspaces.org/
这种?