这是一个创建于 1365 天前的主题，其中的信息可能已经有所发展或是发生改变。
以前买了很多小商家的 VPS，想用同一个公钥连接 SSH 比较方便。想问下如果系统被商家做过手脚，使用同一个公钥有安全风险吗？
第 1 条附言 · 2021-03-31 12:52:29 +08:00
感谢大家的回复，我知道公钥是无法还原私钥的，但是我想知道 SSH 连接过程中我发送的验证数据是否有可能泄露我的隐私呢？
 |
1
whee1 2021-03-31 12:05:53 +08:00 via iPhone
云环境下，即使没有私钥匙，云提供商一样能访问你的系统。
|
 |
2
naoh1000 OP @whee1 #1 不信任的机器我肯定不会存放敏感数据，想问的是如果机器系统被动过手脚，有没可能通过我连接时发出的验证数据和公钥还原出什么隐私数据（包括但不限于连接发起者信息 / 私钥的部分信息）。
|
 |
3
lsylsy2 2021-03-31 12:15:29 +08:00
@naoh1000 不会，公钥的设计就是可以公开，外观是“SSH 公钥”还是“GPG 公钥”还是你访问银行网站银行给你的“https 证书”是没有（原理上）区别的。
|
 |
4
xmumiffy 2021-03-31 12:16:22 +08:00 via Android
有能用公钥还原私钥的技术还开什么 vps,直接去银行提钱不爽么
|
 |
5
Osk 2021-03-31 12:17:49 +08:00 via Android
现实应用中，公钥是可以公开给所有人的。
因为公钥是公开的，所以一般不会用私钥来加密数据，只用来解密数据。所以公钥公开是安全的。 估计 ssh 也有类似的动作，不会用私钥加密数据，所以应该是安全的 ..... 吧 |
 |
6
Mutoo 2021-03-31 12:19:43 +08:00  2
能想到的风险就是使用同一个公钥可以关联同一个使用者。如果有匿名需求的话，最好不要使用公开过的公钥。
|
 |
7
BeautifulSoap 2021-03-31 12:25:36 +08:00
可以了解下非对称加密的基本原理
你 https 访问 google 就能拿到 google https 给你加密用的公钥，全球公开。公钥本来就是公开的，没有问题，以现在的算力也没人能从公钥反向出私钥的信息 然后 lz 既然都以 vps 的系统被动手脚为前提了，那作手脚的人哪还需要这么拐弯抹角。。。。。 |
|
8
naoh1000 OP 感谢大家的回复，我知道公钥是无法还原私钥的，但是我想知道 SSH 连接过程中我发送的验证数据是否有可能泄露我的隐私呢？
@lsylsy2 @xmumiffy @Osk @Mutoo @BeautifulSoap |
|
9
lsylsy2 2021-03-31 12:32:40 +08:00 1
@naoh1000 如果服务器被做了手脚的话，服务器可以：
1. 知道操作的人是你 2. 知道你的所有操作 还有就是确保你连接服务器的时候如果对方的公钥（就是第一次链接某个服务器的时候让你 yes 的那个东西）改变了那么不要接受就行了 |
|
11
BeautifulSoap 2021-03-31 12:37:10 +08:00
@naoh1000 你都以系统被做手机为前提了那肯定能啊
|
 |
12
supercaizehua 2021-03-31 12:45:27 +08:00
我有一个问题，你会使用 github 上面其它人提供的一键脚本吗？
如果你会毫不犹豫的使用，仅仅是因为其它人都在用，也没人发现有安全问题，那么我觉得你大可对这些运营商放心，都是一个道理 |
|
13
naoh1000 OP @supercaizehua #12 敏感机器从来不用，测试机器也会先检查再用。
|
|
14
lsylsy2 2021-03-31 12:55:12 +08:00
@naoh1000 顺便感觉我刚才跑题了
你的原问题是“在不信任的机器上使用和敏感机器相同的公钥安全吗？” 那么只要确保不信任的机器的 fingerprint （就是刚才说的 ssh 要输 yes 的东西）没有问题，那么是安全的。 “不信任的机器”只能知道“你是你”，而无法在敏感的机器面前伪装是你 |
 |
15
charlie21 2021-03-31 13:08:55 +08:00
公钥等信息元素，就像任何信息元素一样，是可以被用作形成一个用户画像的。泄露的信息越多，用户画像越准确
但你总是要泄露的 不是么，就像你去商店买鞋子都是在泄露你的脚的尺码给商店人员 |
 |
16
yanqiyu 2021-03-31 13:21:20 +08:00
如果机器是不被信任的（比如公用机器）放一个公钥上去确实是安全的，你甚至可以 curl https://github.com/${username}.keys 拿到大家在 github 上设置的 ssh pubkey
ssh 上去也_往往_是安全的。但是注意要在 ssh 配置里面设置 ForwardAgent no，因为 ForwardAgent 可以用来偷东西。以及记住不要再不受信任的机器上放私钥 /输密码，因为你不知道目标计算机被动了什么手脚。 |
|
17
yanqiyu 2021-03-31 13:26:14 +08:00
顺带提一句，ForwardAgent 不是可以直接偷走私钥，但是可以用你的私钥认证别的机器。但是这一点也足够棘手了，比如 ssh -T [email protected] 看看你在 github 的用户名然后顺着搞破坏之类的。
|
 |
18
Jat001 2021-03-31 13:27:11 +08:00
ssh -v 看一眼好吗，发了什么数据都写着呢，你使用的客户端的信息，支持的加密方法，你的所有公钥，你的 ip 地址等等信息都会被发送
|
 |
20
ryd994 2021-03-31 14:18:02 +08:00 via Android
安全，公钥就是用来公开的。而且你还应该尽可能广的公开，多种渠道相互印证，避免中间人攻击。
github 可以直接下载登记的 ssh 公钥。 |
 |
21
securityCoding 2021-03-31 16:24:22 +08:00 via Android
有个公字表示这个公开的密钥
|
 |
22
liuxu 2021-03-31 21:15:58 +08:00
安全
|
 |
23
no1xsyzy 2021-03-31 21:39:10 +08:00
密钥交换过程不泄漏多余信息是基础啊，D-H 交换就已经可以做到各自秘密了
这不是公钥的问题，这是密钥交换问题，通常不会全部走非对称的，太慢了，SSH 也好，TLS 也好，都是现场交换一个足够强的对称密钥。 |
 |
24
libook 2021-04-01 10:27:34 +08:00
没有物理隔离没法谈安全，最坏的情况就是运营商在 VPS 的软硬件上动了手脚，那你的任何安全措施将没有意义。
除非 VPS 上仅走密文，比如 VPS 上做 TCP 转发 HTTPS 的流量，加密是在你本地的设备上进行的，解密是在远程网站服务器上进行的，VPS 仅走密文且没有解密能力。 或者障眼法，用非主流技术，让运营商看不懂来你在做啥。 不过另一个角度来看，你得评估你的隐私信息对外人来说有多高的价值，以及运营商专门做坏事的成本以及对自己品牌造成的风险（被发现后以后还做不做生意了），综合衡量得出一个运营商做坏事的几率，如果几率较高不能接受就不用，但如果几率较低可以考虑忽略风险。 |
Select Language