这是一个创建于 1650 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如我在.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