谢谢作者 about sshwifty HOT 4 CLOSED

不失望，还是那句，谢谢！！！！

from sshwifty.

文件管理暂时不方便，原因有两个：1) 目前 Sshwifty 的 Websocket 协议效率并不高。如果想要支持大流量数据传输的话，Multiplexer 协议可能需要重新写，以便加入 Per-stream throttle control，但这样工程量和测试量比较大；2) 其实 SFTP 本身还没有成为 IETF 标准。市面上的文件管理程序，比如 scp 用的是现实标准——比如 openssh 库——的实现。

当然啦，其实主要还是因为懒惰，没精力去研究和解决前面那两条。

是否考虑自动自签名的ssh

我假定你想说的是SSL？想要启用 HTTPS 的话，你可以自行利用 openssl 命令行或者其他工具产生一个自签名的证书/私钥对，然后把他们导入 Sshwifty，这个流程与导入由信任CA颁发的证书是一样的。

当然，这并不是“自动自签名”。我猜测“自动自签名”的意思大概是让程序自动在启动时产生证书/私钥对？如果是这样，那么其实并这不是一个好主意。

当（一个安全的）浏览器访问一个自签名服务站台的时候，如果用户选择忽略自签证书警告，浏览器应当记录服务器给出的自签证书，并且按照自签证书的要求进行加密通讯。这其实提供了一层安全保护，因为如果后端服务变更了自签证书（比如在真的发生了中间人攻击的情况下），浏览器会重新警告用户。

所以，一般的安全建议是，如果真的要使用自签证书，那么每个网域/站台都应该使用独立且唯一的证书，而不是频繁的自动产生新证书。因为如果证书被频繁的更换的话，用户就不会认真对待浏览器给出的警告了。

关于 importKey，其实这主要是因为浏览器在前端对 JavaScript API 的安全限制导致的，而不是 Sshwifty 针对连接进行了特殊的处理。简单的说，只要浏览器访问 Sshwifty 的连接是在 HTTPS 上的，那么它就不会施加那些限制。

另外，浏览器是不知道、也不关注这个连接进入 Cloudflare 的基础设施后有没有被解密等等。哪怕你部署的 Sshwifty 后端是明文 HTTP 的，只要 Cloudflare 能让你可以通过 HTTPS 访问到后端，那么浏览器 JavaScript API 安全限制的问题就不应该存在。

希望这能解释你的疑问 :)

from sshwifty.

1.谢谢，我还真不知道sftp不是标准，谢谢科普。大文件没设想过，输入vi命令截获到外挂编辑器考虑一下。vi等实在是应对不了大文件，看着都头疼。当然这是额外额外额外的建议。
2.谢谢解释，事情没问题，只是像我这种自用的，巴不得一个http解决呢，您有更高的考虑没问题，我的意思是不是可以提供个。像个懒人开关
3.写疑问只是顺手，主要是为了表示感谢，太™好用了。还好看。还稳定。尤其是对ipv6的小鸡。套个cf跑起来比本地xshell＋ipv4都爽。

from sshwifty.

为什么我觉得我每次回复都可能会让你更失望 🙃。自动生成随机TLS证书的功能肯定不会有，因为如果做了大概会被安全人士臭骂。

另外截获终端命令（vi那个）的功能也不会有。主要的原因是其实截获命令输入的功能其实是一个 Hack，维护起来会比较麻烦。

这个项目目前能稳定工作的原因之一是由于我在设计项目的时候为其定义了一个边界，即提供网页 SSH、Telnet 终端界面（而不是服务器管理工具之类），这样之后我的工作就是用能力范围内最好的设计和手段达成这一目标。

如果一个附加的功能不能帮助达成上述目标，那么它就不会被添加。原因是，每项新功能都会在实际上增加维护的负担，因为要确保新功能可以与已有的功能进行良好的交互，而不会反之变成阻碍。

到这个事（截获vi命令并启动其他文本编辑器）上，由于终端连接的并不只有 Linux Shell（/bin/sh、/bin/bash之类），所以解析用户输入的指令其实并不像看上去那么容易。即使我添加了截获功能，付出了很多努力让它在/bin/sh、/bin/bash以及/bin/zsh上能够正常工作，一旦有一个我不知道的新 Shell（非常常见，比如一些 BBS 的 Shell），那么程序可能就没办法正常工作了。

所以，针对这个需求，最好的解决方案就是不去添加这个功能。抱歉啦。

另：SFTP 的功能可能未来会有，只是我现在在写其他的东西，还没有时间和精力去看与 SFTP 相关的几个 RFC 草案。

from sshwifty.