这是一个创建于 3751 天前的主题，其中的信息可能已经有所发展或是发生改变。
我现在用密钥管理软件的是keepassX，terminal用的是tilda（看重的是全局F2呼出和透明效果）
但是现在问题就来了，因为是随机生成的密码记不住，不能很方便地在keepassX里连接ssh，每次都要从keepassX里复制然后到tilda里粘贴....
用private key免密码登陆，安全性是一个问题...
难道要写个脚本，然后用keepassX的cmd命令传递ssh用户名和密码到tilda里？
大家有没有更好的办法？
但是现在问题就来了，因为是随机生成的密码记不住，不能很方便地在keepassX里连接ssh，每次都要从keepassX里复制然后到tilda里粘贴....
用private key免密码登陆，安全性是一个问题...
难道要写个脚本，然后用keepassX的cmd命令传递ssh用户名和密码到tilda里？
大家有没有更好的办法？
 |
1
gamexg 2014-09-20 10:49:20 +08:00
用private key免密码登陆，安全性是一个问题...
这个居然安全性问题？？ |
 |
3
lhbc 2014-09-20 11:03:30 +08:00 via iPhone
私钥是可以设置密码的……
|
 |
5
ryd994 2014-09-20 11:03:33 +08:00
|
|
6
ryd994 2014-09-20 11:06:38 +08:00
|
|
8
ryd994 2014-09-20 11:20:00 +08:00
@Radeon 不好意思，我还没见过值得这样纠结安全的。
如果你想万无一失，请务必遵守安全第一准则：物理安全。 用单独的安全主机进行登录，只允许内网登录， 甚至直接塞进保险柜，才是真正可靠的办法。 私钥定期更换，勤查日志，这是基础中的基础。 |
 |
10
sdysj 2014-09-20 12:23:08 +08:00
用 SSH Agent 之类的管理器就行了，keepass 有插件的我记得。 keepassx 就不要期望有什么解决方案了。
|
 |
11
Radeon 2014-09-20 12:36:56 +08:00
|
|
12
ryd994 2014-09-20 13:20:00 +08:00
@Radeon 所以安全用户，或者安全主机是很有用的，我上面已经说了。sudo的作用不只是sudo到root。定期更换私钥，检查登录日志更是基本中的基本。用密码登录就不怕读取了？只要不是hash，就都有解密的可能。
|
|
13
Radeon 2014-09-20 13:21:54 +08:00
@ryd994 sudo是完全不能用的。原来只有root有最高权限，允许sudo用户ssh的话就有一大堆可以获得root权限的路径呢
|
 |
14
skybr 2014-09-20 13:28:16 +08:00
既然假设恶意软件能读到~/.ssh, 那通过写~/.bashrc、~/.profile、~/bin/劫持一下ssh命令捕获密码也难不到哪里去吧.
|
 |
19
dant 2014-09-20 13:35:14 +08:00 via iPhone
跳板服务器
|
|
20
Radeon 2014-09-20 13:36:00 +08:00
@ryd994 谨慎一点的话可以看modified time，或者把对自己的w权限关掉。sudo这个机制绝对不能在生产环境用的，生产环境应该只允许最低权限的用户登录，必要时执行一下su
|
|
22
ryd994 2014-09-20 13:38:00 +08:00
不好意思打错sudoers
|
|
23
Radeon 2014-09-20 13:40:56 +08:00
@ryd994 不管sudoer能做什么。一个系统只需要低权限登录账号和root账号就可以管理，任何多余的机制只会增加被攻击表面
|
 |
25
66450146 2014-09-20 13:50:10 +08:00
..我还以为大家都会给 private key 设置 passphrase 呢
|
 |
27
onemoo 2014-09-20 14:08:07 +08:00
@Radeon
我们说私钥安全，你说私钥可能泄露。 我们说私钥+密语安全，你说密码也不安全。 那你只用密码岂不更不安全！ 你用密码管理软件也只是“增加了密码获取的链条，但是没有额外的安全性”，你还是把超长的密码记在脑子里吧... |
|
28
Radeon 2014-09-20 14:11:12 +08:00
@onemoo 临时输入的密码明显比一直留在硬盘上的可以读取的密码安全。输入的密码只要排除key logger和shell history就可以了，这个很容易排除
|
 |
29
fany 2014-09-20 14:14:33 +08:00  1
@yylzcom 楼主可以看看兽兽这篇文章呀！http://ttt.tt/104/
|
|
30
66450146 2014-09-20 14:28:41 +08:00
@Radeon private key + passphrase 可以非常有效地防御穷举攻击，不知道“没有额外的安全性”这话从何说起。一个临时输入的密码不会比一个保存的密钥额外加上一个临时输入的密码安全，例如前者就无法防御中间人攻击。
绝对的安全性是不存在的。每一点安全性的增加，都会提高入侵的成本。当入侵的成本明显小于收益的时候，这个系统就可以说是基本安全的。 |
 |
31
ttimasdf 2014-09-20 15:09:52 +08:00
额，没有人提到keepass是可以增加otp加密数据库的？你要想的话，把keepass的数据库用那种小玩意加密，然后设备扔到保险箱不就好了么。。嫌费钱直接用Google Authencator也行啊。。
但是这个，用密码登录很都比啊…… 私钥的话，只要保证包含privatekey的主机物理安全就好了。楼上都说过了。 no zuo no die =w= |
 |
32
ctexlive 2014-09-20 15:26:22 +08:00 via Android
@Radeon 你好像不懂sudo能干什么。而且ssh用私钥是为了避免网络上的劫持监听，而不是本地安全。
|
 |
33
kafkakevin 2014-09-20 15:27:05 +08:00
@Radeon 私钥权限是400（or 600 我不太记得），文件属于某个用户，
怎么会“随便一个app都能读取呢”？ |
|
35
Radeon 2014-09-20 15:30:17 +08:00
@kafkakevin 你开的进程继承你的uid，然后就有r权限啊
|
|
37
ctexlive 2014-09-20 15:33:27 +08:00 via Android
用密钥加上密钥本身密码（只在本地调用密钥时临时使用，不会明文传递到网上），远远比你直接用密码登录sssh安全。这都是成熟的安全认证方。需要争论吗？
|
|
38
kafkakevin 2014-09-20 15:34:27 +08:00
|
|
39
Radeon 2014-09-20 15:35:16 +08:00
@ttimasdf 你确定你能保证你的登录机的物理安全？如果你用随身的mac做登录机你确定你的mac上每个程序都是可信的（这个我承认确实能做到）？或者别人不会在借用你的mac的时候拷走~/.ssh/？
|
|
40
Radeon 2014-09-20 15:37:11 +08:00
@kafkakevin 你开个shell，默认继承shell父进程的uid，最后一路回朔到login或者图形化的gui-login
|
 |
41
aku 2014-09-20 15:37:43 +08:00
我觉得还是弄成两步登陆安全，并且防止暴力破解
不知道有没有好的方案？ |
|
43
Radeon 2014-09-20 15:41:54 +08:00
@aku 你两步登录，第一步用跳板账号登录的时候如果用.ssh下的私钥方案，一样会被泄漏。然后光是跳板账号就有很多r权限，已经算被半个攻陷了
|
|
44
kafkakevin 2014-09-20 15:43:27 +08:00
@Radeon 我登陆shell的用户跟ssh服务的用户根本不是一个用户，用户A能读只有用户B才能读得文件？ 怀疑。 你说的继承那个我听不懂。
|
|
45
Radeon 2014-09-20 15:47:21 +08:00
@ctexlive 我不需要随机密码来保护我。我只要密码足够长然后每次手动输入就行了。这和用~/.ssh/秘钥的本质区别在于我的硬盘上没有长期保存的秘钥等着别人来拷走。我每次手动输入，如果没有key logger和shell history的话密码只存在ssh的进程里，会话结束就消失了
|
|
46
Radeon 2014-09-20 15:49:38 +08:00
@kafkakevin 假设你的机子上有个第三方程序，你启动它不就给了它的进程你的uid？这样你能读你的~目录，这个进程也能读。很明白吧？
|
|
47
ctexlive 2014-09-20 15:51:29 +08:00 via Android
|
|
48
Radeon 2014-09-20 15:54:27 +08:00
@ctexlive 给密码加密码只不过是增加密码链条长度，很多情况下是无意义的。口令的好处我再说一遍，在于没有持久化在硬盘上的可供破解的东西。在其他条件都相同的情况下，当然不给你的敌人任何可破解的原始材料更安全
|
|
49
ctexlive 2014-09-20 15:55:13 +08:00 via Android
@Radeon 你根本就没搞清楚为什么用口令直接登录ssh不安全在哪里。（什么通过口令长度来防止中间人攻击，这是开玩笑吧？）。你能给ssh服务器加长口令，为什么不能给本地密钥增加长口令？即便被考走也得暴力破解。
|
|
51
ttimasdf 2014-09-20 15:57:26 +08:00
@Radeon 用keepass管理随机生成的长密码，keepass数据库用one time pass加密。长密码加密ssh私钥。公网与内网用两套公私钥。
程序可信这个不好做到，但是我觉得最不可信的只有zsh的说 这套方案如果有什么缺陷请告诉我，因为我自签发的证书也这么管理的=v= |
|
53
Radeon 2014-09-20 16:00:34 +08:00
@ctexlive 我没说通过口令长度来防止中间人攻击。我说口令长度足够长就行了。用口令本身也是防止中间人攻击的，所有的验证算法都要用到密钥exchange/Agreement算法，是安全的，所以请不要扯什么中间人攻击这回事
|
|
55
ctexlive 2014-09-20 16:01:53 +08:00 via Android
@Radeon 网络上的中间人攻击远比物理本地接触你电脑再破解难度低多了（严谨的服务商都会禁止直接用口令登录）。物理隔绝也远远比网络防护简单多了。真不知道你为什么独独对没有客户端服务端验证的口令那么有信心。
|
|
56
ctexlive 2014-09-20 16:04:46 +08:00 via Android 1
@ttimasdf 用口令主要不是为了直接劫获明文密码，而是防止中间人攻击。比如你登录ssh服务器时用口令不会验证对方身份，真实服务器也不会验证客户端的身份，于是就被中间人登录服务器了。
|
|
59
Radeon 2014-09-20 16:09:04 +08:00
@ctexlive 你第一次登录真实主机的时候ssh会记录下它的公钥，之后你假如被DNS劫持，中间人服务器由于没有主机的私钥是不能和你记录下来的公钥匹配的，你会得到报警！
但是这是验证对方主机身份，和你用临时输入的密码还是~/.ssh/来提供你的身份证明没有关系 |
|
60
Radeon 2014-09-20 16:17:00 +08:00
@ttimasdf 你的系统的安全依赖于Keep Pass这类Keychain程序的安全性。恶意程序可以先拷走你的Keep Pass数据库和~/.ssh/（因为它的进程有你的uid），然后等Keep Pass出安全漏洞他好本地加速破解
|
|
61
kafkakevin 2014-09-20 16:20:53 +08:00
@Radeon 我启动这个第三方程序，那么这个程序是用我的登陆用户（比如user0）启动的，如果user0的家目录的某文件A的权限是可以读，那当然能读。
但是，ssh服务是用ssh的专有用户启动的，这个用户的shell时nologin，是不能登陆的，所以，第三方程序是无法做到你所说的”继承其UID“。 |
|
62
Radeon 2014-09-20 16:22:58 +08:00
@kafkakevin 第三方程序被你启动了以后能读你的~/.ssh/*，这你承认么？承认的话是否承认密钥泄漏了呢？ ssh服务在远程机器上，我根本不用关心ssh服务
|
|
63
ctexlive 2014-09-20 16:39:35 +08:00 1
@Radeon 用ssh口令不能避免中间人攻击。即便你认为第一次拿到的服务器公钥是“真实”的，那也只能知道单方面服务器是否真实，服务器不知道客户端是谁。如果ssh本身就可以防止中间人攻击，那从ssh代替telnet以后就不可能出现广泛的中间人攻击模式了。你现在无非基于：1. .ssh/*被自己运行的程序读取。（别人已经告诉你，用sudo等控制权限的方法或者用其他单用账户，sudo不是让你获取高权限，同样可以限制某用户使用更低权限，而且禁用了root账户更安全，从上文看你一直认为sudo会获取更高权限，这种想法是错误的）。2.你认为.ssh/*被获取，即使加了密钥密码还是可被暴力破解。既然如此，你又如何保证你的keepassX不被人获取且暴力破解呢？为什么独独担心前者而不担心后者？因为按照你的逻辑，后者同样是“密码的加密链”。3. 物理隔绝永远比保证网络安全更容易简便。不放心自己的本地电脑，那就把密钥存到第三方硬件设备，基于同样的理由，你也应该把keepassX数据库存到第三方硬解，否则也会被获取暴力破解，你不能独独担心前者而不担心keepassX，更何况密钥的密码同样是不记录在电脑中的，甚至不传输到网络上。
|
 |
64
zwy100e72 2014-09-20 16:44:12 +08:00
各位大神争论的真是精彩，看的我眼花缭乱的。。。
网上有人表示保存密码就等于没有密码，我想这句话多少是有一定道理的。 公钥加密码登录的确能够防止有程序直接读取私钥导致泄漏，但是毕竟人类的记忆能力有限，有资料表示一般人能记住6个不同的密码已经算是极限了，而且我猜这个密码的长度不超过32位。 如果采用密码管理软件的话，需要记住的密码变成了一个。。。看起来安全程度还不如直接记密码。。 私钥加密钥口令的薄弱环节也相差不大，看起来很类似于用密码管理软件。。。 不管用私钥还是公钥，只要是ssh登录，都会验证服务器的RSA指纹，亦即服务器公钥，所以无论怎么登陆如果存在中间人攻击，都可能提示错误（或者伪造指纹后都不提示）。 方便与安全乃鱼与熊掌，不可兼得。要方便，还是选择私钥加私钥口令；要安全，请使用服务器口令加私钥加私钥口令，再加一大堆东西。。。甚至有些秘密绝对不能留下可供查证的记录。。。 以上仅为小弟愚见（本人大二），如有错误，欢迎指正。 |
|
65
kafkakevin 2014-09-20 17:19:00 +08:00
@Radeon 哦，那我明白了。我误以为是ssh服务。抱歉。
|
 |
66
wzxjohn 2014-09-20 17:24:44 +08:00
最好的办法是进行双重认证，现在有很多解决方案，比如原来有一个A啥玩意的我忘了，可以装一个App，每次SSH连接到服务器之后需要输入Code，付费之后可以使用短信。就像谷歌验证器一样。或者楼主可以自己写一个程序嘛，做一个以谷歌验证器为基础的SSH验证服务相信不是很难。
|
|
67
Radeon 2014-09-20 17:27:22 +08:00
@ctexlive 首先你最好先学习一遍密码学原理这样我们可以统一词汇表。
1）使用登录密码，ssh基于密钥交换/推导算法建立会话秘钥，不会把登录密码在网络上传输。整个过程用服务器的公钥验证服务器，用户的账号密码验证登录用户，这是没有问题的。 2）用户开启的进程有读~/.ssh/*的权限，它要愿意2秒钟就读完并回传到它的服务器上了，你还很难检测出来。这是一个事实 3）默认配置下sudo机制导致知道sudoer的密码就等于知道root密码。不论怎么说sudo后的用户权限一定比sudo前高，这就会导致安全问题。这个问题是虚假的安全感：很多人以为禁掉root只用sudoer账号就安全了，其实根本不是这么回事。sudoer密码泄漏通常造成的影响和泄漏root密码一样的。不用sudo机制，管理员一定会加强管理root密码，用了sudo（特别是多个sudo账号），管理难度就陡然上升 4）我不推崇用Keep Pass等Keychain工具。原因很简单，我绝不在硬盘上留下任何可以被破解的原始材料。所有条件一样的情况下，临时输密码一定比用存在硬盘上的key安全 |
 |
68
JoeyChan 2014-09-20 17:58:59 +08:00
私钥600权限+口令验证，口令就不要随机了，设置一个记得住的就够了。
|
|
69
ctexlive 2014-09-20 18:43:17 +08:00
@Radeon
1）使用登录密码，ssh基于密钥交换/推导算法建立会话秘钥，不会把登录密码在网络上传输。整个过程用服务器的公钥验证服务器，用户的账号密码验证登录用户，这是没有问题的。 ----------------------------- ssh口令登陆,采用的是服务器的公钥加密(密码包括其他传输内容)后传输到服务器端.有问题吗?密码验证这个环节是在服务器完成的而不是你的客户端本地. 我已经说的很明白了,属于单方验证状态, 即使假定你第一次获得的公钥是"真实"(因为ssh服务器公钥是服务器端自己制作的,和https不同),你只能识别出是否后续公钥是否有变动(和首次获取的比),服务器不能识别客户端身份. 2）用户开启的进程有读~/.ssh/*的权限，它要愿意2秒钟就读完并回传到它的服务器上了，你还很难检测出来。这是一个事实 ------------------------------ 已经告诉你了. 能读取~/.ssh/* 同样可以读取keepass 数据库. 这也是事实. ssh你自己的私钥,以及keepass都可采用本地密码加密.这没有本质区别. 获取后还是采取暴力破解. 3) 默认配置下sudo机制导致知道sudoer的密码就等于知道root密码。..用了sudo（特别是多个sudo账号），管理难度就陡然上升 ------------------------------ 不是ubuntu默认的那种获取root权限的方式,sudo可以精确定义A用户是否可用B用户执行某个程序/脚本.不仅仅是替代root那么简单的. 没人说"让你用默认配置",事实上大部分linux系统的默认配置是不启用用户权限.你可以建立一个帐户,用sudoer赋予一些管理系统命令的权限,专门用来做日常维护管理. 你也可以建立低权限的C帐户,并赋予一些程序的执行权限,ssh用于登陆服务器用. 你可以把你的ssh私钥扔那个账号下即可. 既然谈本地安全了,就别说"用默认配置",或者"保留root帐户反而会加强root密码".你这明显是想当然. 这个软方案就是用来解决你担心的"执行未知程序被读取~/.ssh/*"的问题. 4).我不推崇用Keep Pass等Keychain工具。 ------------------------------ 从你原文看你并没表达这个意思.从记录看,你是在讨论中才转变看法的.事实上正如我说的,既然担心本地密码加密的ssh私钥被读取,同样理由也要担心keep pass的数据库. 而且也给出一个解决方案了,用usb key这样的第三方硬件工具来管理. 或者手机等工具辅助的二次验证方式,丢了密码都不担心. 显然这些方案都比前面说的软件方案都麻烦. |
|
70
Radeon 2014-09-20 18:52:48 +08:00
@ctexlive 如果同意我们都公认使用~/.ssh/*登录是很脆弱的方案，那么抬杠就可以中止了。我选择临时输入密码，你选择二次验证或者硬件密钥这不冲突
|
|
71
ctexlive 2014-09-20 19:02:36 +08:00 via Android 1
@Radeon 我没觉得密钥验证方式脆弱。我倒是觉得很安全，而且你用keepass管理的密码也谈不上临时，keepass数据库存储本来就和ssh密钥（本地密码二次加密）存在一样的问题，我就是搞不懂你所谓的更安全怎么得出来。
|
 |
72
LazyZhu 2014-09-20 19:07:28 +08:00
1. 如果只是本地ssh登录远程服务器的话，只需要服务器配置publickey，而无需privatekey。。。
2.如果服务器需要用到privatekey的话，keeppass有keeagent插件，支持windows/Ubuntu/Mint/Debian，privatekey以附件方式存于keepass加密数据库中。。。 http://lechnology.com/software/keeagent/usage/options-and-settings/ |
 |
75
Tink 2014-09-20 22:27:41 +08:00 via iPhone
私钥很靠谱啊
|
|
76
ryd994 2014-09-21 04:18:06 +08:00
|
 |
77
SharkIng 2014-09-21 09:12:48 +08:00
正常的管理Linux服务器都是证书/私钥 加 私钥密码，从没听说过比私钥还安全的了
当然你要说你设置一个非常长的密码到也行，可是不方便记忆不说，密码也有泄露的一天啊，那怎么办？ 如果这么说岂不是误解了？？ |
|
80
ryd994 2014-09-21 12:10:28 +08:00
@Radeon
明白sudo能干啥没？有sudor到某一个用户的权限不代表有sudo到root的权限。 这样就可以避免私钥随便被拷走了。 除了root没有人能拷走，而且可以规定sudo只允许执行ssh。 密码再长也是人记的，而私钥2048位就可以称安全了（目前破解最多不到1024）。 |
|
81
ryd994 2014-09-21 12:12:58 +08:00
真正需要安全，就别开远程登录
|
|
82
ryd994 2014-09-21 12:15:27 +08:00
有空看看安全日志，看看root密码被人穷举了多少次。
|
|
83
ryd994 2014-09-21 12:25:45 +08:00
私钥加密是可以ssh-add，然后在登出之前都不需要再输密码了。
改~/.ssh/config也可以改变默认私钥文件的位置。还不至于有哪个恶意软件会这么聪明先搜索。 总体来讲还是物理安全重要的多。使用安全主机，甚至禁止远程登录，才是真正可靠的安全。 其实sudo一开始的目的就是提供有限的管理权限：root是不用于日常维护，而只允许本地登录的。 |
|
84
SharkIng 2014-09-22 03:16:32 +08:00
@Radeon 拷贝走了之后没有任何影响，密钥是加密的，没有密码一样白搭啊。
如果说用穷举法破解，那么你服务器的密码一样可以这样破解 密钥相当于一个证书和一个密码，两层保护，也许是依然有一定风险但是总的来说还是比密码好很多的，而且还方便 |
|
85
SharkIng 2014-09-22 03:18:48 +08:00
@ryd994 我觉得他们所怕的就是私钥泄露，我对密码学没什么研究不知道这有多大的影响，但是至少我看来及时泄露没有密码的情况下也是白搭，密码还有可能泄露呢何况一个文件
不知道我的理解对不对：即使我公布我的私钥，在私钥密码非常强大的情况下普通人也没办法很容易破解出来，相当于一个废文件罢了，对于他们得到私钥的人没有任何意义 |
|
86
ryd994 2014-09-22 08:27:15 +08:00 1
@SharkIng 也不对，
比如服务器可以限制穷举频率，banIP等，这是私钥做不到的。但我同意你说的如果私钥正确生成，即使拿到私钥也很难破解 因为私钥是aes加密的。尽管目前证明AES在某些情况下复杂度小于理论值，但增加密钥长度即可。 私钥登录并不多一个证书，因为即使密码登录，服务器会即时创建一个随机密钥用于通讯，你的密码是在加密通道里传输的。我的理解是：关闭私钥主要是为了防穷举 我的意见是：如果本地被攻陷，一切白搭。密码私钥唾手可得。所以本地安全是前提，而最安全就是不要root ssh，一个长期稳定运行的系统是不需要很多root操作的，这些操作应该用suid或者有限sudo解决。 |
|
87
Radeon 2014-09-22 10:35:29 +08:00
@ryd994
quote "明白sudo能干啥没？有sudor到某一个用户的权限不代表有sudo到root的权限。 这样就可以避免私钥随便被拷走了。" 不懂你在说什么。私钥在终端机上，和服务器上的sudo没有关系 |
|
88
Radeon 2014-09-22 10:42:03 +08:00
@ryd994
quote "比如服务器可以限制穷举频率，banIP等，这是私钥做不到的" 这就是我说的其他条件一样的情况下，不留下任何硬盘上的可供破解的原始资料更安全。今天你觉得AES是安全的，也许NSA不觉得，或者过了2年AES被曝有重大缺陷怎么办？那时候你的pass phrase保护的密钥早被人拷走了，在你修复漏洞前攻击者先出手了怎么办 |
|
89
Radeon 2014-09-22 10:45:58 +08:00
|
|
90
ryd994 2014-09-22 11:02:29 +08:00
@Radeon
1. “不懂你在说什么。私钥在终端机上，和服务器上的sudo没有关系” 无论是客户机还是服务器，sudo都不是无限的。如果你的管理员连自己电脑安全都无法保证的话，我建议你换个人。 我说客户机上sudo是这样用的：新建一个禁止登录的用户，把私钥chown给他，今后登录的时候用sudo ssh。文件系统的permmison可以保证任何人无法读私钥，sudoer设置则可以允许某个用户以另一个用户的身份执行某程序，sudo者，被sudo者，程序，都是可限制的。 而服务器上一般用sudo比用suid少，但是两种方法都可以实现同样的效果，即非root赋予有限的管理权限。 当然，如果你客户机root被盗那就什么都没用了，无论密码还是私钥。 2. “这就是我说的其他条件一样的情况下，不留下任何硬盘上的可供破解的原始资料更安全。今天你觉得AES是安全的，也许NSA不觉得，或者过了2年AES被曝有重大缺陷怎么办？那时候你的pass phrase保护的密钥早被人拷走了，在你修复漏洞前攻击者先出手了怎么办” 同上，正确使用不存在此问题。 另外，加密从来就不是无限的。用密码还有窃听的风险呢，你怎么不说rsa加密通道的安全性？这就是我说物理隔离，安全客户机，甚至禁止root远程的原因 3. “本地安全根本没有想象中好做到。开发调试阶段开发机往往被用作登陆终端。开发机上安装的软件鱼龙混杂，而且个个能读 ~/.ssh/*。开发机会被带着到处跑，会丢” 还是那句话：如果你的管理员连自己电脑安全都无法保证的话，我建议你换个人。专机专用，这是安全的基本 |
|
91
Radeon 2014-09-22 11:18:16 +08:00
|
|
93
ryd994 2014-09-22 11:33:17 +08:00
@Radeon 保证密码强度也是管理员安全基本素养之一。
私钥密码主要还是为了减轻客户机物理接触的危害，比如我上面说的sudo法也无法阻止一个能操作客户机的恶意用户，这个恶意用户不能读取私钥，却可以直接使用，如果没密码就直接能登录了。 尽管如此，AES也不是吃素的。想穷举私钥成本不小，在发现之前能争取足够的反应时间足矣。 |
|
97
Radeon 2014-09-22 11:59:13 +08:00
@ryd994 我总结一下我的观点。任何password及其用加密链保护的变体不能保存在计算机媒介上，写在餐巾纸或者记成口诀、七言绝句都更安全。
如果一定要保存在计算机媒介上（这时已经败了），加密链上的每个保护密码的强度必须大于被保护对象才有意义 |
Select Language