这是一个创建于 1945 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如我在.ssh 目录下配置了 config 文件，
里面包含了服务器主机名、用户名和私钥文件路径。
如果我本地项目引入了恶意的依赖包，
运行时读取了 config 文件内容、私钥文件，并被黑客利用，
那么我服务器登录信息不是泄漏了？
 | 1 lxk11153 2020-06-20 22:25:32 +08:00 感觉这有点类似你加入一个 wifi 一样，如果 wifi 是黑 wifi，那你不就啥都被看到了吗？既然我选择连接这个 wifi 就代表我选择尽量相信它或者产生风险我也许能接受。 |
 | 2 codehz 2020-06-20 22:25:44 +08:00 不仅如此，恶意软件包还能修改你的 shell 配置直接获得 root 权限（例如在 bashrc 里 alias sudo，替换成恶意的版本） |
 | 3 Oysmart 2020-06-20 22:25:58 +08:00 config 都泄露了，何来安全？ |
 | 4 litmxs 2020-06-20 22:28:12 +08:00 via Android 生成密钥的时候设置密码。 |
 | 5 sky96111 2020-06-20 22:41:33 +08:00 私钥非 root 不可读，ssh config 可以被读虽然不安全，倒也不至于直接被登陆 |
 | 6 guog 2020-06-20 22:53:19 +08:00 via Android 权限 400 |
 | 7 timothyye 2020-06-20 22:53:26 +08:00 via Android 密钥可以设置密码 |
 | 8 jiangzm 2020-06-20 23:07:44 +08:00 那你就不要用.ssh/config 文件，怕这怕那的。 我猜是你自己想做这个事，一般公开的依赖包不会做这么低级的事。 |
 | 10 shunf4 2020-06-20 23:38:32 +08:00 用 Deno 吧，少年 |
 | 11 toaruScar 2020-06-21 01:12:29 +08:00 可以考虑用 ssh 证书登陆。把签名了的密钥的有效期设成 1 天，然后每天重新签发私钥就行了。 |
 | 14 whitegerry 2020-06-21 02:22:46 +08:00 config 放其他位置，改个名字一样用嘛，ssh -F path/trojan linux |
 | 15 alphatoad 2020-06-21 07:05:10 +08:00 via iPhone  1 私钥加密码，用你的发行版的密码管理器管理，可以无感 |
 | 16 yanqiyu 2020-06-21 07:30:01 +08:00 via Android 1 当然，用户自己凭本事安装的程序系统只能信任了。所以要保证软件来源可控。 真要被恶意程序感染，恶意程序还能偷走 chrome 的保存的密码，这才叫灾难（ |
 | 17 ClericPy 2020-06-21 10:16:18 +08:00 没有绝对的安全, 跳板机, LDAP 登录, 动态口令, 各种东西都敌不过一行代码漏洞 |
 | 18 expy 2020-06-21 11:42:08 +08:00 直接行恶意程序，当前账户有权限的文件都暴露了。 |
| 19 codehz 2020-06-21 13:16:38 +08:00 1 @sky96111 #5 是非当前用户不可读（不然 ssh 怎么读到的私钥），所以如果开发机上用同一个用户跑恶意程序还是能被偷走的 |
 | 20 dorentus 2020-06-21 17:14:32 +08:00 via iPhone 私钥加密码，或者放硬件模块中（比如 yubikey ） |
 | 22 dingwen07 2020-06-21 23:48:09 +08:00 via iPhone 1 私钥用 PGP 转，然后存储在无法导出的智能卡里，nitrokey 、yubikey 这种 不过 Linux 如果不乱信任密钥恶意软件包进不来吧，包管理都是要验证 PGP 密钥的 |
 | 23 ruzztok 2020-06-22 09:34:57 +08:00 私钥权限好像必须是 600，你查一下便知 |
 | 24 libook 2020-06-22 10:25:04 +08:00 Linux 的权限机制很强大也很灵活，所以安全与否全在于管理员制定什么样的策略。 首先，权限最小化原则。任何应用程序都应该运行在一个特定的用户下，这个用户仅被授予应用程序运行所必须的权限，即便不小心在应用程序上引入了恶意代码，也因为没有事先授予权限而无法进行更高级别的破坏；影响也被限制在应用程序层面。 一旦准许一个用户被 SSH 登入，那么只要它可以进入一个正常的 Shell，就拥有了这个用户的所有权限，但通常配置“是否准许一个用户被 SSH 登入”是需要高级权限的（比如 root ），那么完全可以禁止应用程序运行所使用的用户被 SSH 登入，可以使用另一个用户作为 SSH 登入专用的用户，然后将这个用户的权限限制在仅能使用 su 指令切换到其他用户，而 su 指令是需要输入切换的目标用户的口令才可以的，安全性有保证。同时建议在服务器上禁用或移除 sudo 指令。 |
| 25 libook 2020-06-22 11:07:36 +08:00 SSH 只是一种远程连入的方式，而登录到一个用户是有很多种方法的，有正常的方法，也有利用漏洞越权操作的方法，所以最好彻底禁用运行应用程序的用户被登录，也就是说哪怕我从别的用户使用 su 指令要求切过去，甚至哪怕我走到机房里直接操作那台机器输入正确的账号密码，都不能直接登录这个受限用户（在不能登录到 root 用户改系统配置的情况下）。 用户的登录是由系统底层来控制的，系统配置里会记录不同用户对应的默认 Shell 是什么，然后当用户登录成功的时候会自动启动相应 Shell 以便于用户操作，但如果系统里对应这个用户配置的 Shell 不是一个可用的 Shell （比如 /sbin/nologin ），那么即便用户登录成功了也无法操作。 具体方法可以参考这个： https://www.thegeekdiary.com/unix-linux-how-to-lock-or-disable-an-user-account/ Deno 只是个应用引擎，顶多带有一定的沙盒功能，Deno 的依赖包是直接暴露在 Linux 文件系统里的，不是放在 Deno 沙盒的文件系统中，而沙盒只能保证代码使用沙盒来执行的时候不会逃逸（越权），但无法保证代码不利用沙盒以外的机制运行，理论上恶意代码完全可以不依赖 Deno 来访问当前用户的所有权限（比如 Linux 系统层级的木马，利用系统的调用来自动运行，或者冒充正常程序引诱管理员运行）。 如果确实有需要将代码与 Linux 系统进行隔离，可以使用具备文件系统隔离能力的方案，比如容器和虚拟机，所有代码都存在于 image 中，不会直接被系统或管理员调用，必须在容器或虚拟机里运行，而容器和虚拟机确保其不会逃逸。 用容器和虚拟机还有一个好处，就是 image 可以在 CI 环境里构建，构建完成能够进行安全扫描，确保没有恶意代码再部署到服务器正式环境，这样也可以消除恶意代码在应用业务层上的破坏。 |
 | 26 warcraft1236 2020-06-22 11:14:06 +08:00 不是，你本地都起了恶意程序了，还怎么保证安全？ 我一直没搞明白，你自己的电脑已经被注入恶意程序了，怎么还能天真的认为本地数据是安全的呢？ |
 | 27 shellus 2020-06-22 15:30:46 +08:00 1 如果它能读取到 ~/.ssh/config 那么它也能读取到~/.bash_history 和 ~/.ssh/id_rsa 你只担心~/.ssh/config 干嘛？ |
Select Language