是否可以在配置文件中添加一个新选项【"baseURL"】，用于控制访问的URL？ about sshwifty HOT 18 CLOSED

关于主要的问题：抱歉，这无法实现。因为事实上Sshwifty的前端程序是在编译时生成的，其中包括路径（即base_url）信息。并且这些生成的代码已经在编译时绑定在二进制程序里了。想要变更的话，只能通过自行修改 webpack.config.js#L188 和 controller.go#L38 并重新构建程序的方式来实现。

建议如果有可能的话，你可以通过子域名的方式（如ssh.domain.name）的方式来部署Sshwifty。如果一定要通过二级路径的方式部署的话，可以尝试使让Nginx去重定向指定路径前缀的请求，参考 #10 (comment) 。当然后面一种方式比较脏而且并没有真正的解决问题，因此不建议。

就与预设相关的问题：按照目前的设计，预设其实仅仅是自动填表功能，并且会保存 Session 信息（指本身只会在当前页面有效，页面刷新后失效的数据，其中包括登录密码之类的敏感信息。这些信息在通过正常向导连接时则不会被保存）。在用户通过Preset向导连接过一次之后，“Connected before”列表中会出现之前的连接记录，用户只需要通过点击这些记录就能进行自动连接了，不需要再使用Preset。因此，“Connected before”连接记录的存在其实是有意义的。

就“New remote”这个Tab在当OnlyAllowPresetRemotes被设置为true时仍会显示这一问题，目前的设定确实会造成一些困扰，我会在后面的版本做出修正。

就快捷键相关的问题：关于遮挡的问题，你可以试试在不使用快捷键栏（其实叫Toolbar）的时候关闭它；关于可配置的快捷键，我会思考如何去实现这一功能（实现这项功能需要改动一些架构，没有看起来那么简单），不过我在忙于其他的项目，在那些项目完成之前大概不会有时间去做这些。

我猜测你是在手机上使用Sshwifty因此遇到了这样的问题。如果是这样的话，最好的办法是连接一个实体键盘，这样就不需要使用Sshwifty内置的快捷键了。

关于公网部署安全性的问题：Sshwifty的Websocket数据包其实是用AES加密的（但是没有Replay保护，因此你仍然需要HTTPS）。你在Sshwifty的登录页面输入的密码会在之后作为加密密钥的一部分来加密数据载荷，如果Sshwifty后端无法通过正确的密钥解密数据包，它会断开连接。也就是说，不知道正确登录密码的人是无法连接Sshwifty后端Websocket接口的，也因此就无法命令Sshwifty后端去执行任何操作。

当然如果你不放心的话，可以用Nginx加一层HTTP Auth，这样可以避免任何未授权的人访问Sshwifty的任何部分。

不过，最后还是抱歉啦，您最主要的要求没有目前办法达成 :(

from sshwifty.

感谢你的回复，虽然明确了不能通过增加"BaseURL"的方式去定义二级路径，实现反向代理，你确实感谢你提供可能的解决方案。之所以想到使用二级路径作NGINX的匹配反代，是因为我在使用动态域名服务和花生壳的内网穿透去连接家里的服务器，基于花生壳的内网穿透原理，我这个情况下没有办法通过自定义DNS解释的"A"记录去作匹配；而如果使用阿里云的域名解释服务，又没办法使用默认的80和443端口[再加路由器上的端口影射实现]；所以才会提出是否可以增加"BaseURL"的想法。

对于“Connected before”，应该是我说得不够清晰，我的意思并不是完全的移除这个页面，而是建议以单独的页面去做这件事；毕竟当我看到这些“已经连接过的服务”，突然的出现在预设连接“PRESETS”的页面上时，我感觉到严重的打乱了原来预设连接页面的美观性；对于预设连接页面的“Connected before”功能的实现，我是建议了以另外的展示方式去实现这个功能/目的，见前面第三点内容；

对于快捷键，这只是我的一个设想而且，毕竟让你去实现这个我感觉对于一个开源工具来说，有点过份了。我已经想到了要实现这项功能的复杂性；显然不会是一个按钮关联一个命令那么简单，例如不同预设连接对应不同的命令版本[这个个人感觉要做的话，将命令与按键绑定设定在JSON配置文件内比较合适]；在UI方面要怎么向用户清晰的传达在使用的按键等；

关于安全性的问题，经过你的解释，我大概了解他的安全程度了。说实话，那个密码认证框是我最喜欢这个WEBSHH的其中一点，大部分的WEBSSH都没有这个功能。以目前的安全措施来说，局域网使用，已经完全足够了！但如果说要暴露于公网使用的话，这个安全措施显然远远不够！单密码认证的方式，连最基本的暴力破解也不足以抵挡。当然，我可以利用NGINX或APACHE的“HTTP Auth”增加一层防护，但显然我不想用那个丑陋的“HTTP Auth”去遮挡那个原本漂亮的界面。其实基于“连接预设”这一个功能，这已经和一个通常的SHELL终端没多少区别了，在这一个情况下，如果用户设置了“预设连接”并暴露于公网，一但密码被爆破成功，这将意味着用户丢失了所有“预设连接”服务器的控制权了，这显然是一个极大的安全问题！那如果暴露于公网，但不设定“预设连接”，密码被爆破，那安全吗？显然也不是，虽然没有了丢失服务器控制权的风险，但这个WEBSSH依然可以作为网络攻击中，其中代理跳板的其中一环，用于隐藏网络攻击者的攻击途径。显然基于单密码认证方式下，本工具在公网使用个人认为风险还是比较高。

所以说，如果作者你本来的希望是将其暴露于公网使用[我感觉你是这个想法]，首先要处理的可能是安全认证的问题。对于安全性加强的方法，我有以下几个想法。1、增加验证码功能[拖动验证也可考虑]，当然这个验证码功能是可以关闭的，因为内网使用的话，这个只会增加操作的复杂性；这基本是公网防暴力破解的最基本的方法了；2、增加一个“USER”配置项，这个配置项的值其实没什么实质性的意义，他可以是任意字符组合，但两个文本框的输入可以大大增加暴力破解的难度；另外，这一配置项也可以配合实现第3点想法的功能实现；3、增加锁定功能，即用户连接输入错误密码X次，锁定X分钟；以上这些增加安全性的功能，可以通过配置项一次性屏蔽，毕竟内网使用的话，当前的设定已经足够了。

当然，我这些想法其实和现在网站使用的防爆破手段基本一样，所以也不算是想法；

以上这些只不过是我一些想法，毕竟我的确比较喜欢你这个项目。我只会搭服务，不写代码，所以我也帮不上什么忙[主要是我不想写代码，那个太苦逼了；而且有你们这些人在，我还折腾什么代码~~]。我不是摧你更新啊，毕竟我知道这种东西都只是基于兴趣在做我只是觉得你这个项目有机会可以成为一个功能强大的WEBSHELL，所以说了点想法主要是做得漂亮啦~~

from sshwifty.

如果你是购买了花生壳内网映射服务的话，那么看来只能用我上面提供的那个比较Hack的二级目录方案了。不过需要注意的是，由于Sshwifty的特性，用户的数据，包括“Connected Before”中的内容是存储在客户浏览器的localStorage中的（服务器上不会储存任何数据）。同时，由于浏览器的安全策略，同一个主机名下的所有程序都可以访问这个主机名下localStorage容器中的数据。简单的说，如果你在这个主机名下安装了别的程序，他们也能读取Sshwifty所储存的记录。你需要权衡一下安全性。

至于“Connected Before”和“Preset”方面，其实我的设计是让Preset只需要执行一次，然后用户只需通过“Connected Before”上的记录进行后续连接就可以了，这样一来还可以免去重新运行连接向导的麻烦。所以这两个列表才出现在一个页面上——因为需要提供一个方便的界面让用户去发现这些连接记录。

另外，Preset的目的并不是为了提供一个终端列表，而是允许管理员设置一些主机的连接选项以便让用户去方便的连接（#14）。如果你有安全方面的考虑，则不应该使用Preset，也不要把机密信息放在Preset里，因为这些数据是会以明文方式发送给客户端的，包括密钥和密码。你可以看一下 README.md#configuration-file 里关于Preset的警告。

另：你不需要在Preset里设置所有的选项（Meta Field）。当一个Field不存在时，用户可以在连接向导里自定义其中的值。

就你的用例来说，最好的方式还是在连接完想要连接的SSH主机后，将“Connected Before”的记录导出到文件里，并将这个文件分享给到其他需要使用Sshwifty的客户端。这样配合Nginx的HTTP Auth，可以避免未授权的访问和数据泄露。你可以在“Known remotes”面板的最下面找到Import/Export的功能。

from sshwifty.

你好，我尝试通过你所提供的方式，使用"sshwifty"作为二级路径进行反向代理，得到了以下错误。

所使用的配置是：
`# SshWifty 服务
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}

location = /sshwifty/socket {
proxy_pass http://sshwifty_m:8182/sshwifty/socket;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
}

location /sshwifty/ {
rewrite ^/sshwifty/assets/(.) /sshwifty/assets/$1 break;
rewrite ^/sshwifty/(.) /$1 break;
proxy_pass http://sshwifty_m:8182 ;
}
`

我使用的是DOCKER的镜像，但是当我直接使用镜像，并且不使用反向代理的情况下，服务是可以正常运行的；

from sshwifty.

啊，抱歉。我在提供完那个Issue里的nginx.conf之后，又在后面的某个版本中修改了一下Sshwifty的接口URL（将/sshwifty/socket和/sshwifty/socket/verify分离了），导致之前的nginx.conf失效了。

你试试将上面配置里的location = /sshwifty/socket改成location /sshwifty/socket，也就是去掉=，然后reload Nginx看是不是正常了。

如果还不行的话我可能需要进一步测试nginx.conf里其他的选项。不过我目前没有测试环境，大概需要等周一了。

from sshwifty.

你好，我通过取消"="的方法，可以正常访问到认证页面了，但我尝试使用配置文件中的密码进行认证时，出现了如下界面：

"verify"文件的指向连接依然未有改变；

啊~~不好意思，我在项目的首页看到了，要使用HTTPS。

from sshwifty.

我这边已经修改了 Issue 10#issuecomment-562925134 中的 nginx.conf，新的配置考虑进了变更后的URL。如果未来有需要你可以参考它修改配置你的Nginx。

from sshwifty.

恩，我现在在使用"/sshwifty"作为二级路径，对比了一下你最新的更新连接，和原来相比应该就是删除了"="号；关于"upstream"我自己的配置中没有使用，这个应该不影响，毕竟这个也没有需要做负载均衡/备份服务器的需要。

我有点时间，又测试了了一下"import/export"的功能；我突然发现这个功能非常好，你应该把这个功能做成一个更明显的按键；测试中，当“"OnlyAllowPresetRemotes": true”时，当通过"import"导入的主机不在预设配置中时，连接会被拒绝，这应该是符合你的预期设计的。但我个人觉得，可以开放这一个限制，理由见下：

对于一个可以暴露于公网使用的服务来说，我一直都是非常关注安全性的，所以一直在想怎样可以将这一个服务暴露于公网，而又能保证安全，"import"这一个功能我突然发现可以通过一些合理的设定，实现暴露于公网使用的安全上的需要；暴露于公网使用，我个人认为“"OnlyAllowPresetRemotes": true”是必须的，这能防止服务成为代理跳板。然后通过"import"功能导入预设配置进行SSH连接，那用户便能随时使用SSHWIFTY进行服务器管理了，而对于用户来说，用户只需要一个U盘保存这些文件，或在手机上保存这些文件，便能随时随地的使用SSHWIFY了。

当然，对一个开源工具来说，任务人都可以通过阅读代码，自行生成对应的配置文件以使用SSHWIFTY；所以，这些配置文件需要进行加密处理，在"config.json"增加一个字段，指定任意的字符串，用于加解密这些"import"文件；通过这样的方式，不同用户生成的"import"文件就不再一样了，也就是不同用户无法使用非他们搭建的SSHWIFTY了，这样安全性的问题就解决了。

通过这样的方式，暴露于公网的SSHWIFTY，指定“"OnlyAllowPresetRemotes": true”，并且也不需要进行连接预设，而是仅需要保存一份只有自己知道加解密符串的"import"文件，即可在任意地方管理自己的服务器了，也不存在安全问题了~~

from sshwifty.

OnlyAllowPresetRemotes的意思是“仅允许连接Preset中定义的远程主机”。如果你不设定任何Preset同时将OnlyAllowPresetRemotes设定成true的话，Sshwifty就不会允许任何连接了。

如果你想限制一个公共Sshwifty实例的访问能力，可以：

• 设定OnlyAllowPresetRemotes为true，定义好所有的Preset，但不要提供登录凭据（比如密码或密钥）。这样用户在使用那些Preset的时候需要手动输入登录凭据才可以连接
• 让Sshwifty后端通过一个能够进行访问控制的Socks5代理进行连接，你可以通过Socks5系列设置来让Sshwifty去使用指定的Socks5代理
• 通过iptables去限制Sshwifty后端的Outgoing。

Sshwifty的连接记录（即“Connected Before”中的数据）是保存在客户端的，Import/Export也是纯客户端的，因此对这些数据进行加密其实并没有什么意义了。

from sshwifty.

OnlyAllowPresetRemotes的意思是“仅允许连接Preset中定义的远程主机”。如果你不设定任何Preset同时将OnlyAllowPresetRemotes设定成true的话，Sshwifty就不会允许任何连接了。

• 这一点我明白，我测试"import"功能时就确定了这是你的设计思路；

以下均在我假设的SSHWIFTY的最基本认证，即"SharedKey"被暴力破解后的前提下[无任何限制措施的单文本框认证我个人认为基本对暴力破解没良好的防御能力，若提高密码的复杂程序，我感觉又提高了这个工具的易用性]；

设定OnlyAllowPresetRemotes为true，定义好所有的Preset，但不要提供登陆凭据（比如密码或密钥）。这样用户在使用那些Preset的时候需要手动输入登陆凭据才可以连接。

• Preset在安全上的问题是，任何通过了基本认证的人，都可以通过预设值知道你服务器的IP与SSH所使用的端口，显然，从安全角度来说，我不希望任何人可以获取到这些信息，尤其是那些通过暴破基本认证进入SSHWIFTY的人。正如你所说，我可以不提供密码或密钥实现目的，但我希望能有更优秀的易用性；

让Sshwifty后端通过一个能够进行访问控制的Socks5代理进行连接，你可以通过Socks5系列设置来让Sshwifty去使用指定的Socks5代理。

• 这可能是一个措施，但这意味着，如果我要确保安全的使用SSHWIFTY，那么我还需要额外的多部署一个服务。？？这意味着使用者需要额外的多管理一项服务……那对于安全性的考虑，使用者又要多考虑一个服务的安全性？

通过iptables去限制Sshwifty后端的Outgoing。

• 其实这基本同上，增加了使用的难度，当然，在你提出的方案中，这个基本就是最便捷的方案了。这个方案的问题在于，如果用户每增加一台管理主机，则意味着用户每一次都需要到SSH的宿主服务器上建立一个IPTABLE规则，而我觉得，实际中会使用IPTABLE的人并不多

Sshwifty的连接记录（即“Connected Before”中的数据）是保存在客户端的，Import/Export也是纯客户端的，因此对这些数据进行加密其实并没有什么意义了。

• “Connected Before”加密在我的想法中是有意义的，他的意义在于阻止攻击者通过'构造“import”文件'利用SSHWIFTY作为攻击跳板中一环去实施攻击。当然，以目前的状态来说，这个加密的意味可能不算太大；但加密至少在目前状态下可以防止通过对"import"文件解释出目标服务器的IP/PORT/密码/密钥；我举个例子可能能更清晰表达我的想法，如下：

1. 攻击者通过暴力破解"SharedKey"进入SSHWIFTY；
2. OnlyAllowPresetRemotes状态设定为"true"，攻击者无法通过"New remote"自定义连接，将SSHWIFTY作为代理跳板使用；
3. Preset为空，攻击者无法获取任何有关用户有关任何服务器的任何信息，攻击者仅有可能通过"import"的方式，构造"import"文件，对攻击者已知的目标服务器[肉鸡]实施连接，并把SSHWIFTY作为其中代理跳板中的一环来使用；
4. 配置文件中存在一个加密字段选项，用于加密"import"文件，攻击者无法通过SSHWIFTY的源代码逆向解释构造自定义的"import"文件，而将被攻破的SSHWIFTY用作代理跳板。[因为"import"文件需要服务器的解密字符串解密后才能使用，而每个用户设定的加密字符必定不一样，而且这个加解密字符串完全可以做得足够复杂]
5. 用户，携带加密的"import"文件，可以于任何有互联网连接的地方实施对其目标服务器的管理，而他也不需要担心在公网使用的SSHWIFTY服务被暴力破解后，带来任何的社会性危害。用户携带的"import"文件丢失，加密后的“import”文件在不知道加密字符串的前提下，无法逆向解释出任何有关服务器的内容。当然，这丢失的"import"文件依然可以通过部署在线的SSHWIFTY连接至用户的服务器，但显然，这是用户自己的安全管理问题了。
6. 在这个想法下，用户只需要IMPORT，导入文件即可管理自己的服务器了，不需要记密码，不需要同时携带私钥，不需要担心SSHWIFTY暴露与公网的安全性，不需要担心SSHWIFTY被暴力破解。

当然，这只是我一厢情愿的想法~~~我只是说一下我的想法，作者你有自己的想法，项目也是你的，你应该按你的想法去设计这个工具，我只是一个参考~~~

from sshwifty.

不是的，当你删除了那些Preset之后，Sshwifty将不再会允许用户连接到那些远程主机，哪怕Sshwifty客户端本地仍然有"Connected Before"的记录。

from sshwifty.

你说的我都知道啊，看来我还是没说清楚我的意思，

现在SSHWIFTY公网使用存在以下问题【建立在基本认证被暴力破解后】
1.OnlyAllowPresetRemotes状态设定为"true"，则必须使用"Preset"，被暴力破解后存在服务器信息漏泄的风险；
2.OnlyAllowPresetRemotes状态设定为"false"，"Preset"为空，被暴力破解后存在成为攻击代理跳板的风险；
3.OnlyAllowPresetRemotes状态设定为"false"，"Preset"不为空，被暴力破解后存在成为攻击代理跳板的风险及服务器信息泄漏风险；

from sshwifty.

如果你是想阻止未经授权的访问，那么可以通过在Nginx上设定HTTP Auth并配合fail2ban之类的程序来实现。有什么原因使你认为此项功能无法通过其他程序或方式达成，因而必须添加进Sshwifty？（除了你之前提到的不美观之外）

from sshwifty.

嗯~我并没有说配合其它工具不能实现，但如果工具本身就有能力可以满足，那为什么需要依赖于第三方提供安全？

我之前测试只是简单的测试，也没发现"Preset"原来是可以不设定密码这类参数的，所以我一直以为预设必须填写完整的服务器资料；另一方面我想问一下，"Preset"既然可以不填写预设密码，那么是不是也可以不填写一些其它的参数？例如用户？以另一个方式来问，或者是，OnlyAllowPresetRemotes状态设定为"true"时，"Preset"中的那一个参数决定了，此“预设连接”是否可以成功连接至目标服务器？

=================

如你所说，"Preset"可以不设定密码这类参数的【我已经测试了，的确可以】，那通过SSH的公钥登录，已经满足安全需要了。在这个设定我，我基本了解你的安全设计方式。应该就是：

• 在OnlyAllowPresetRemotes状态为"true"下，通过"Preset"设定预设不含密码/私钥的连接，以控制可以访问的目标服务器，用户需要手动输入密码或导入密钥来实现连接。
• 在OnlyAllowPresetRemotes状态为"true"下，如果用户通过"import"导入"已经连接过的服务器"，因为"import文件"中实际已包含了密码/私钥，所以其只需要符合"Preset"规则即可实现连接；
• 即要实现较强的安全性需要"OnlyAllowPresetRemotes"/"Preset"/"import"三者的合理配置实现；

=================

在这个方式下，我想问一下，是否可以提供一个选项，以控制"Preset"的预设连接是否在前端中显示?
即在OnlyAllowPresetRemotes状态为"true"，"Preset"的预设连接在前端不显示的状态下，用户只能通过"import文件"实现对目标服务器的连接；即用户不希望在前端暴露任何有关其管理服务器的信息，如地址/端口；

=================

最后问一下，已经连接过的目标服务器可以通过"export"导出，而作为另一主机上的"import文件"，此文件如果结合你的代码，逆向解释出当中的服务器地址/端口/密码/私钥的可能性存在吗？

from sshwifty.

但如果工具本身就有能力可以满足，那为什么需要依赖于第三方提供安全？

一些功能并没有你想的那么简单，比如你上面提到的通过增加一个字段来提高破解难度，其实你把密码设置的长一点结果是一样的。如果你仍然不放心，可以去用Nginx的HTTP Auth，并调试它的相关选项来增强安全性。此外，你说去加密导出的连接记录，这也是没有意义的，因为Sshwifty是在客户端处理那些记录的。

第三方工具往往提供了更强大的管理功能，这些功能往往经过了多年的优化，利用这些工具去实现你想要的功能显然比让我去民科一个更合适。

最后，你要知道这是一个开源并且免费的程序，所以我在维护的时候主要考虑的不是添加功能，而是保持维护的低成本。注意：这也是你能免费使用这个软件，而不需要每月向我支付￥45使用费的原因。

我之前测试只是简单的测试，也没发现"Preset"原来是可以不设定密码这类参数的，所以我一直以为预设必须填写完整的服务器资料；另一方面我想问一下，"Preset"既然可以不填写预设密码，那么是不是也可以不填写一些其它的参数？例如用户？以另一个方式来问，或者是，OnlyAllowPresetRemotes状态设定为"true"时，"Preset"中的那一个参数决定了，此“预设连接”是否可以成功连接至目标服务器？

你可以不填写Meta中的任何字段。如果客户端没有检测到对应字段，则会允许用户在Connector向导里自行输入。另外，如果你好奇的话，“远程主机名”（比如Meta中的Host）是特殊字段，它的值会被Preset下Host中的值所替换，无论是在是用SSH还是在使用Telnet时。

我之后会将相关说明明确的写在在README.md里的。

此文件如果结合你的代码，逆向解释出当中的服务器地址/端口/密码/私钥的可能性存在吗？

Sshwifty将连接记录分为两个部分，一部分是“常规信息”，其中包含了远程服务器的地址和端口，以及连接相关的其他选项，这部分信息是在导出的文件当中的；还有一部分被称为“Session信息”，本意是“仅仅在当前的页面可用，页面关闭（Session消失）后丢失”。“Session信息”中保存了密钥等机密信息。“Session信息”的储存和导出是特殊的：

• 当用户通过正常的Connector向导连接时，“Session信息”只会保存在内存里，页面关闭后丢失。这些信息也不会出现在导出的文件里；
• 在0.2.7-beta版本中，当用户通过Preset连接时，“Session信息”会被保存在导出的文件里；
• 在0.2.7-beta之后的版本中（目前尚未发布），当用户通过Preset连接时，如果Preset中提供了“Session信息”，则这些信息会被保存在导出的文件中，否则不会。

你可以在打开Sshwifty客户端页面的浏览器窗口按F12键然后使用控制台命令JSON.parse(localStorage.getItem("sshwifty-knowns"))命令查看Sshwifty储存了什么数据。

另外，导出的数据并没有加密，你可以通过在浏览器控制台使用JSON.parse(atob(导出的数据))来解开它。

from sshwifty.

JSON.parse(localStorage.getItem("sshwifty-knowns"))

你给出一个非常了不得的功能函数！！！于是我又基于这个功能函数做了一些测试！
导入"import文件"，通过你提供的方法，我获取到了"import文件"中的所有有关服务器设定的数据，包括密码/密钥；
另外，我也尝试了在另外的服务器上导入"import文件"，同样可以获取所有有数据；这意味着包含密码/密钥的"import文件"非常重要，一但丢失有完全泄露服务器所有信息的风险；这个如可能应在"README.md"以明确的方式告知用户；

当然，以上这一切应该在你的预期之内；

另一方面，我也测试了在存在"CONNECTED BEFORE"时，在未通过"AUTHENTICATION REQUIRED"的情况下使用JSON.parse(localStorage.getItem("sshwifty-knowns"))，结果显示也同样可以获取所有有关服务器的信息。这意味着任何用户，在任何公众场合，在使用完SSHWIFTY后，都应该完全的清理"CONNECTED BEFORE"；这个如可能也应在"README.md"以明确的方式告知用户；其实我好像见到过有关这个的提示，但我突然又找不到了；

关于45元/月，有点贵了吧，单位是月啊~~~~而且我也给你做测试啊，也提供建议，就免费了吧，哈哈~~~

from sshwifty.

这意味着包含密码/密钥的"import文件"非常重要，一但丢失有完全泄露服务器所有信息的风险；这个如可能应在"README.md"以明确的方式告知用户；

这是因为你在使用0.2.7-beta，这样的行为已经在36#issuecomment-751567251中说明清楚了。在下一个版本中，在Preset连接过程中由用户输入的密码/密钥不会被保存，这项变更已经在两天前由 bf1fd7c 实现了。

from sshwifty.

Hi，你好，新版本0.2.7-beta已经发布，针对你上面提到的在OnlyAllowPresetRemotes为真的情况下，"New remotes"的显示进行了修正。现在，如果OnlyAllowPresetRemotes被设置为true，当用户第一次打开Connector窗口的时候，默认会切换到“Known remotes”标签页。

然而你的其他提议由于各种考虑没有被接受，抱歉。

from sshwifty.