大家在 debian/ubuntu 下如何管理 ssh 密码 - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Distributions
Ubuntu
Fedora
CentOS
中文资源站
网易开源镜像站
yylzcom
V2EX    Linux

大家在 debian/ubuntu 下如何管理 ssh 密码

  •  
  •   yylzcom 2014 年 9 月 20 日 9686 次点击
    这是一个创建于 4235 天前的主题,其中的信息可能已经有所发展或是发生改变。
    我现在用密钥管理软件的是keepassX,terminal用的是tilda(看重的是全局F2呼出和透明效果)

    但是现在问题就来了,因为是随机生成的密码记不住,不能很方便地在keepassX里连接ssh,每次都要从keepassX里复制然后到tilda里粘贴....

    用private key免密码登陆,安全性是一个问题...

    难道要写个脚本,然后用keepassX的cmd命令传递ssh用户名和密码到tilda里?

    大家有没有更好的办法?
    100 条回复    2014-09-22 22:52:16 +08:00
    gamexg
        1
    gamexg  
       2014 年 9 月 20 日
    用private key免密码登陆,安全性是一个问题...

    这个居然安全性问题??
    yylzcom
        2
    yylzcom  
    OP
       2014 年 9 月 20 日
    @gamexg 不好意思,没说清楚,是怕私钥泄露……
    lhbc
        3
    lhbc  
       2014 年 9 月 20 日 via iPhone
    私钥是可以设置密码的……
    Radeon
        4
    Radeon  
       2014 年 9 月 20 日
    @gamexg 用private key一点也不安全。随便什么应用都能读 ~/.ssh/下面的文件
    ryd994
        5
    ryd994  
       2014 年 9 月 20 日
    @yylzcom
    1. 私钥是有密码的,如果用得多可以ssh-add暂时解开,重启又锁上
    2. 要安全,第一就是物理隔离,自己的电脑不要让别人沾手
    3. 严格权限隔离,sudo之前认真想清楚
    ryd994
        6
    ryd994  
       2014 年 9 月 20 日
    @Radeon
    不见得吧,除了乱七八糟的软件,正常系统服务都是自有用户的。
    至于乱七八糟的软件……linux下不开源的尽量不用
    另外,chown到另一个禁止登录的用户,要用的时候sudo过去也是不错的主意
    Radeon
        7
    Radeon  
       2014 年 9 月 20 日
    @ryd994 智者千虑必有一失
    ryd994
        8
    ryd994  
       2014 年 9 月 20 日
    @Radeon 不好意思,我还没见过值得这样纠结安全的。
    如果你想万无一失,请务必遵守安全第一准则:物理安全。
    用单独的安全主机进行登录,只允许内网登录,
    甚至直接塞进保险柜,才是真正可靠的办法。

    私钥定期更换,勤查日志,这是基础中的基础。
    ffffwh
        9
    ffffwh  
       2014 年 9 月 20 日
    @Radeon
    读 ~/.ssh 这个无解吧,真碰上恶意软件还能监听键盘呢。
    sdysj
        10
    sdysj  
       2014 年 9 月 20 日
    用 SSH Agent 之类的管理器就行了,keepass 有插件的我记得。 keepassx 就不要期望有什么解决方案了。
    Radeon
        11
    Radeon  
       2014 年 9 月 20 日
    @ryd994 @ffffwh

    你们误解我的意思了。防~/.ssh/不被第三方软件读取的难度和防键盘监听器/物理安全的难度不是一个层次的。我假设你们日常使用Mac,目前很少有人用Mac只从AppStore装软件。假设处于新奇测试了一个AppStore之外的软件/桌面Widget呢,由于对方是二进制不开源的,是否读取~/.ssh是很难觉察的,一旦有损失是很大的
    ryd994
        12
    ryd994  
       2014 年 9 月 20 日
    @Radeon 所以安全用户,或者安全主机是很有用的,我上面已经说了。sudo的作用不只是sudo到root。定期更换私钥,检查登录日志更是基本中的基本。用密码登录就不怕读取了?只要不是hash,就都有解密的可能。
    Radeon
        13
    Radeon  
       2014 年 9 月 20 日
    @ryd994 sudo是完全不能用的。原来只有root有最高权限,允许sudo用户ssh的话就有一大堆可以获得root权限的路径呢
    skybr
        14
    skybr  
       2014 年 9 月 20 日
    既然假设恶意软件能读到~/.ssh, 那通过写~/.bashrc、~/.profile、~/bin/劫持一下ssh命令捕获密码也难不到哪里去吧.
    Radeon
        15
    Radeon  
       2014 年 9 月 20 日
    @skybr 改写~下的文件容易被查出来啊,读一下~/.ssh没有记录啊
    ryd994
        16
    ryd994  
       2014 年 9 月 20 日
    @Radeon /etc/sudoer配置…………
    ryd994
        17
    ryd994  
       2014 年 9 月 20 日
    @Radeon 查改写也没那么容易,你平时有看这些文件的习惯么?
    ryd994
        18
    ryd994  
       2014 年 9 月 20 日
    @Radeon 密码登录ssh是逗比行为,正规的服务器基本都要禁止的…………
    dant
        19
    dant  
       2014 年 9 月 20 日 via iPhone
    跳板服务器
    Radeon
        20
    Radeon  
       2014 年 9 月 20 日
    @ryd994 谨慎一点的话可以看modified time,或者把对自己的w权限关掉。sudo这个机制绝对不能在生产环境用的,生产环境应该只允许最低权限的用户登录,必要时执行一下su
    ryd994
        21
    ryd994  
       2014 年 9 月 20 日
    @Radeon 请先查查suduer文件能控制什么………………
    ryd994
        22
    ryd994  
       2014 年 9 月 20 日
    不好意思打错sudoers
    Radeon
        23
    Radeon  
       2014 年 9 月 20 日
    @ryd994 不管sudoer能做什么。一个系统只需要低权限登录账号和root账号就可以管理,任何多余的机制只会增加被攻击表面
    Radeon
        24
    Radeon  
       2014 年 9 月 20 日
    @ryd994 sudo机制只要输入sudoer的密码而不是root密码,这是非常可怕的,很容易流失权限控制
    66450146
        25
    66450146  
       2014 年 9 月 20 日
    ..我还以为大家都会给 private key 设置 passphrase 呢
    Radeon
        26
    Radeon  
       2014 年 9 月 20 日
    @66450146 本质上只是增加了密码获取的链条,但是没有额外的安全性
    onemoo
        27
    onemoo  
       2014 年 9 月 20 日
    @Radeon
    我们说私钥安全,你说私钥可能泄露。
    我们说私钥+密语安全,你说密码也不安全。
    那你只用密码岂不更不安全!

    你用密码管理软件也只是“增加了密码获取的链条,但是没有额外的安全性”,你还是把超长的密码记在脑子里吧...
    Radeon
        28
    Radeon  
       2014 年 9 月 20 日
    @onemoo 临时输入的密码明显比一直留在硬盘上的可以读取的密码安全。输入的密码只要排除key logger和shell history就可以了,这个很容易排除
    fany
        29
    fany  
       2014 年 9 月 20 日   1
    @yylzcom 楼主可以看看兽兽这篇文章呀!http://ttt.tt/104/
    66450146
        30
    66450146  
       2014 年 9 月 20 日
    @Radeon private key + passphrase 可以非常有效地防御穷举攻击,不知道“没有额外的安全性”这话从何说起。一个临时输入的密码不会比一个保存的密钥额外加上一个临时输入的密码安全,例如前者就无法防御中间人攻击。

    绝对的安全性是不存在的。每一点安全性的增加,都会提高入侵的成本。当入侵的成本明显小于收益的时候,这个系统就可以说是基本安全的。
    ttimasdf
        31
    ttimasdf  
       2014 年 9 月 20 日
    额,没有人提到keepass是可以增加otp加密数据库的?你要想的话,把keepass的数据库用那种小玩意加密,然后设备扔到保险箱不就好了么。。嫌费钱直接用Google Authencator也行啊。。

    但是这个,用密码登录很都比啊……

    私钥的话,只要保证包含privatekey的主机物理安全就好了。楼上都说过了。
    no zuo no die =w=
    ctexlive
        32
    ctexlive  
       2014 年 9 月 20 日 via Android
    @Radeon 你好像不懂sudo能干什么。而且ssh用私钥是为了避免网络上的劫持监听,而不是本地安全。
    kafkakevin
        33
    kafkakevin  
       2014 年 9 月 20 日
    @Radeon 私钥权限是400(or 600 我不太记得),文件属于某个用户,
    怎么会“随便一个app都能读取呢”?
    Radeon
        34
    Radeon  
       2014 年 9 月 20 日
    @66450146 临时输入的密码也可以防御中间人攻击,这个不要搞错
    Radeon
        35
    Radeon  
       2014 年 9 月 20 日
    @kafkakevin 你开的进程继承你的uid,然后就有r权限啊
    Radeon
        36
    Radeon  
       2014 年 9 月 20 日
    @ctexlive 用临时输入的密码和用公私钥都能防止中间人攻击
    ctexlive
        37
    ctexlive  
       2014 年 9 月 20 日 via Android
    用密钥加上密钥本身密码(只在本地调用密钥时临时使用,不会明文传递到网上),远远比你直接用密码登录sssh安全。这都是成熟的安全认证方。需要争论吗?
    kafkakevin
        38
    kafkakevin  
       2014 年 9 月 20 日
    @Radeon 没听懂。 打比方,我开个shell,继承哪个的UID了?

    开个什么进程能继承ssh的UID呢?

    线上的服务器一直用私钥验证,没有因“私钥验证”出过安全问题。
    Radeon
        39
    Radeon  
       2014 年 9 月 20 日
    @ttimasdf 你确定你能保证你的登录机的物理安全?如果你用随身的mac做登录机你确定你的mac上每个程序都是可信的(这个我承认确实能做到)?或者别人不会在借用你的mac的时候拷走~/.ssh/?
    Radeon
        40
    Radeon  
       2014 年 9 月 20 日
    @kafkakevin 你开个shell,默认继承shell父进程的uid,最后一路回朔到login或者图形化的gui-login
    aku
        41
    aku  
       2014 年 9 月 20 日
    我觉得还是弄成两步登陆安全,并且防止暴力破解
    不知道有没有好的方案?
    ctexlive
        42
    ctexlive  
       2014 年 9 月 20 日 via Android
    @Radeon 难不成你每次登录ssh后就修改ssh密码不成?如果不是,请问随机在哪里?
    Radeon
        43
    Radeon  
       2014 年 9 月 20 日
    @aku 你两步登录,第一步用跳板账号登录的时候如果用.ssh下的私钥方案,一样会被泄漏。然后光是跳板账号就有很多r权限,已经算被半个攻陷了
    kafkakevin
        44
    kafkakevin  
       2014 年 9 月 20 日
    @Radeon 我登陆shell的用户跟ssh服务的用户根本不是一个用户,用户A能读只有用户B才能读得文件? 怀疑。 你说的继承那个我听不懂。
    Radeon
        45
    Radeon  
       2014 年 9 月 20 日
    @ctexlive 我不需要随机密码来保护我。我只要密码足够长然后每次手动输入就行了。这和用~/.ssh/秘钥的本质区别在于我的硬盘上没有长期保存的秘钥等着别人来拷走。我每次手动输入,如果没有key logger和shell history的话密码只存在ssh的进程里,会话结束就消失了
    Radeon
        46
    Radeon  
       2014 年 9 月 20 日
    @kafkakevin 假设你的机子上有个第三方程序,你启动它不就给了它的进程你的uid?这样你能读你的~目录,这个进程也能读。很明白吧?
    ctexlive
        47
    ctexlive  
       2014 年 9 月 20 日 via Android
    @aku 如果真要担心密钥本地被读取,给密钥加密码已经非常安全了即便密钥泄露也是需要暴力破解才行,实在不行还可以用硬件密钥(如密钥优盘)。真不懂@Raden说的 直接用口令登录ssh服务器安全在哪里。
    Radeon
        48
    Radeon  
       2014 年 9 月 20 日
    @ctexlive 给密码加密码只不过是增加密码链条长度,很多情况下是无意义的。口令的好处我再说一遍,在于没有持久化在硬盘上的可供破解的东西。在其他条件都相同的情况下,当然不给你的敌人任何可破解的原始材料更安全
    ctexlive
        49
    ctexlive  
       2014 年 9 月 20 日 via Android
    @Radeon 你根本就没搞清楚为什么用口令直接登录ssh不安全在哪里。(什么通过口令长度来防止中间人攻击,这是开玩笑吧?)。你能给ssh服务器加长口令,为什么不能给本地密钥增加长口令?即便被考走也得暴力破解。
    ctexlive
        50
    ctexlive  
       2014 年 9 月 20 日 via Android
    @Radeon 拜托,给密钥加密码“不是给密码加密码”!!不是一回事好吗?你到底用过没?
    ttimasdf
        51
    ttimasdf  
       2014 年 9 月 20 日
    @Radeon 用keepass管理随机生成的长密码,keepass数据库用one time pass加密。长密码加密ssh私钥。公网与内网用两套公私钥。
    程序可信这个不好做到,但是我觉得最不可信的只有zsh的说

    这套方案如果有什么缺陷请告诉我,因为我自签发的证书也这么管理的=v=
    ttimasdf
        52
    ttimasdf  
       2014 年 9 月 20 日
    @ctexlive 顺便问一下,如果用密码而不通过私钥直接登录ssh,密码会被中间人截获吗?(只是懒得查了=v=)
    Radeon
        53
    Radeon  
       2014 年 9 月 20 日
    @ctexlive 我没说通过口令长度来防止中间人攻击。我说口令长度足够长就行了。用口令本身也是防止中间人攻击的,所有的验证算法都要用到密钥exchange/Agreement算法,是安全的,所以请不要扯什么中间人攻击这回事
    Radeon
        54
    Radeon  
       2014 年 9 月 20 日
    @ttimasdf 就ssh来说用密码当然可以防中间人攻击
    ctexlive
        55
    ctexlive  
       2014 年 9 月 20 日 via Android
    @Radeon 网络上的中间人攻击远比物理本地接触你电脑再破解难度低多了(严谨的服务商都会禁止直接用口令登录)。物理隔绝也远远比网络防护简单多了。真不知道你为什么独独对没有客户端服务端验证的口令那么有信心。
    ctexlive
        56
    ctexlive  
       2014 年 9 月 20 日 via Android   1
    @ttimasdf 用口令主要不是为了直接劫获明文密码,而是防止中间人攻击。比如你登录ssh服务器时用口令不会验证对方身份,真实服务器也不会验证客户端的身份,于是就被中间人登录服务器了。
    Radeon
        57
    Radeon  
       2014 年 9 月 20 日
    @ctexlive 我再说一遍ssh本身是防止中间人攻击的,输密码的也是!你怎么老是要说中间人攻击呢?
    ctexlive
        58
    ctexlive  
       2014 年 9 月 20 日 via Android
    @ttimasdf 上面第二句话应该是(而是为了中间人攻击)。
    Radeon
        59
    Radeon  
       2014 年 9 月 20 日
    @ctexlive 你第一次登录真实主机的时候ssh会记录下它的公钥,之后你假如被DNS劫持,中间人服务器由于没有主机的私钥是不能和你记录下来的公钥匹配的,你会得到报警!

    但是这是验证对方主机身份,和你用临时输入的密码还是~/.ssh/来提供你的身份证明没有关系
    Radeon
        60
    Radeon  
       2014 年 9 月 20 日
    @ttimasdf 你的系统的安全依赖于Keep Pass这类Keychain程序的安全性。恶意程序可以先拷走你的Keep Pass数据库和~/.ssh/(因为它的进程有你的uid),然后等Keep Pass出安全漏洞他好本地加速破解
    kafkakevin
        61
    kafkakevin  
       2014年 9 月 20 日
    @Radeon 我启动这个第三方程序,那么这个程序是用我的登陆用户(比如user0)启动的,如果user0的家目录的某文件A的权限是可以读,那当然能读。

    但是,ssh服务是用ssh的专有用户启动的,这个用户的shell时nologin,是不能登陆的,所以,第三方程序是无法做到你所说的”继承其UID“。
    Radeon
        62
    Radeon  
       2014 年 9 月 20 日
    @kafkakevin 第三方程序被你启动了以后能读你的~/.ssh/*,这你承认么?承认的话是否承认密钥泄漏了呢? ssh服务在远程机器上,我根本不用关心ssh服务
    ctexlive
        63
    ctexlive  
       2014 年 9 月 20 日   1
    @Radeon 用ssh口令不能避免中间人攻击。即便你认为第一次拿到的服务器公钥是“真实”的,那也只能知道单方面服务器是否真实,服务器不知道客户端是谁。如果ssh本身就可以防止中间人攻击,那从ssh代替telnet以后就不可能出现广泛的中间人攻击模式了。你现在无非基于:1. .ssh/*被自己运行的程序读取。(别人已经告诉你,用sudo等控制权限的方法或者用其他单用账户,sudo不是让你获取高权限,同样可以限制某用户使用更低权限,而且禁用了root账户更安全,从上文看你一直认为sudo会获取更高权限,这种想法是错误的)。2.你认为.ssh/*被获取,即使加了密钥密码还是可被暴力破解。既然如此,你又如何保证你的keepassX不被人获取且暴力破解呢?为什么独独担心前者而不担心后者?因为按照你的逻辑,后者同样是“密码的加密链”。3. 物理隔绝永远比保证网络安全更容易简便。不放心自己的本地电脑,那就把密钥存到第三方硬件设备,基于同样的理由,你也应该把keepassX数据库存到第三方硬解,否则也会被获取暴力破解,你不能独独担心前者而不担心keepassX,更何况密钥的密码同样是不记录在电脑中的,甚至不传输到网络上。
    zwy100e72
        64
    zwy100e72  
       2014 年 9 月 20 日
    各位大神争论的真是精彩,看的我眼花缭乱的。。。

    网上有人表示保存密码就等于没有密码,我想这句话多少是有一定道理的。

    公钥加密码登录的确能够防止有程序直接读取私钥导致泄漏,但是毕竟人类的记忆能力有限,有资料表示一般人能记住6个不同的密码已经算是极限了,而且我猜这个密码的长度不超过32位。

    如果采用密码管理软件的话,需要记住的密码变成了一个。。。看起来安全程度还不如直接记密码。。

    私钥加密钥口令的薄弱环节也相差不大,看起来很类似于用密码管理软件。。。

    不管用私钥还是公钥,只要是ssh登录,都会验证服务器的RSA指纹,亦即服务器公钥,所以无论怎么登陆如果存在中间人攻击,都可能提示错误(或者伪造指纹后都不提示)。

    方便与安全乃鱼与熊掌,不可兼得。要方便,还是选择私钥加私钥口令;要安全,请使用服务器口令加私钥加私钥口令,再加一大堆东西。。。甚至有些秘密绝对不能留下可供查证的记录。。。

    以上仅为小弟愚见(本人大二),如有错误,欢迎指正。
    kafkakevin
        65
    kafkakevin  
       2014 年 9 月 20 日
    @Radeon 哦,那我明白了。我误以为是ssh服务。抱歉。
    wzxjohn
        66
    wzxjohn  
       2014 年 9 月 20 日
    最好的办法是进行双重认证,现在有很多解决方案,比如原来有一个A啥玩意的我忘了,可以装一个App,每次SSH连接到服务器之后需要输入Code,付费之后可以使用短信。就像谷歌验证器一样。或者楼主可以自己写一个程序嘛,做一个以谷歌验证器为基础的SSH验证服务相信不是很难。
    Radeon
        67
    Radeon  
       2014 年 9 月 20 日
    @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安全
    JoeyChan
        68
    JoeyChan  
       2014 年 9 月 20 日
    私钥600权限+口令验证,口令就不要随机了,设置一个记得住的就够了。
    ctexlive
        69
    ctexlive  
       2014 年 9 月 20 日
    @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这样的第三方硬件工具来管理. 或者手机等工具辅助的二次验证方式,丢了密码都不担心. 显然这些方案都比前面说的软件方案都麻烦.
    Radeon
        70
    Radeon  
       2014 年 9 月 20 日
    @ctexlive 如果同意我们都公认使用~/.ssh/*登录是很脆弱的方案,那么抬杠就可以中止了。我选择临时输入密码,你选择二次验证或者硬件密钥这不冲突
    ctexlive
        71
    ctexlive  
       2014 年 9 月 20 日 via Android   1
    @Radeon 我没觉得密钥验证方式脆弱。我倒是觉得很安全,而且你用keepass管理的密码也谈不上临时,keepass数据库存储本来就和ssh密钥(本地密码二次加密)存在一样的问题,我就是搞不懂你所谓的更安全怎么得出来。
    LazyZhu
        72
    LazyZhu  
       2014 年 9 月 20 日
    1. 如果只是本地ssh登录远程服务器的话,只需要服务器配置publickey,而无需privatekey。。。
    2.如果服务器需要用到privatekey的话,keeppass有keeagent插件,支持windows/Ubuntu/Mint/Debian,privatekey以附件方式存于keepass加密数据库中。。。
    http://lechnology.com/software/keeagent/usage/options-and-settings/
    Radeon
        73
    Radeon  
       2014 年 9 月 20 日
    @cexlive 我从头就不赞成Keep Pass啊
    oott123
        74
    oott123  
       2014 年 9 月 20 日   1
    看到后面我都以为 @Radeon 是楼主了……
    真正的楼主@yylzcom 好像早已不见了……
    Tink
        75
    Tink  
    PRO
       2014 年 9 月 20 日 via iPhone
    私钥很靠谱啊
    ryd994
        76
    ryd994  
       2014 年 9 月 21 日
    @Radeon 能读完文档再说话么?
    http://linux.die.net/man/5/sudoers
    SharkIng
        77
    SharkIng  
       2014 年 9 月 21 日
    正常的管理Linux服务器都是证书/私钥 加 私钥密码,从没听说过比私钥还安全的了
    当然你要说你设置一个非常长的密码到也行,可是不方便记忆不说,密码也有泄露的一天啊,那怎么办?
    如果这么说岂不是误解了??
    Radeon
        78
    Radeon  
       2014 年 9 月 21 日
    @ryd994 读完了。你想说什么
    Radeon
        79
    Radeon  
       2014 年 9 月 21 日
    @SharkIng 说了半天说的是私钥被其他程序轻易拷走的风险啊
    ryd994
        80
    ryd994  
       2014 年 9 月 21 日
    @Radeon
    明白sudo能干啥没?有sudor到某一个用户的权限不代表有sudo到root的权限。
    这样就可以避免私钥随便被拷走了。
    除了root没有人能拷走,而且可以规定sudo只允许执行ssh。
    密码再长也是人记的,而私钥2048位就可以称安全了(目前破解最多不到1024)。
    ryd994
        81
    ryd994  
       2014 年 9 月 21 日
    真正需要安全,就别开远程登录
    ryd994
        82
    ryd994  
       2014 年 9 月 21 日
    有空看看安全日志,看看root密码被人穷举了多少次。
    ryd994
        83
    ryd994  
       2014 年 9 月 21 日
    私钥加密是可以ssh-add,然后在登出之前都不需要再输密码了。
    改~/.ssh/config也可以改变默认私钥文件的位置。还不至于有哪个恶意软件会这么聪明先搜索。
    总体来讲还是物理安全重要的多。使用安全主机,甚至禁止远程登录,才是真正可靠的安全。

    其实sudo一开始的目的就是提供有限的管理权限:root是不用于日常维护,而只允许本地登录的。
    SharkIng
        84
    SharkIng  
       2014 年 9 月 22 日
    @Radeon 拷贝走了之后没有任何影响,密钥是加密的,没有密码一样白搭啊。
    如果说用穷举法破解,那么你服务器的密码一样可以这样破解

    密钥相当于一个证书和一个密码,两层保护,也许是依然有一定风险但是总的来说还是比密码好很多的,而且还方便
    SharkIng
        85
    SharkIng  
       2014 年 9 月 22 日
    @ryd994 我觉得他们所怕的就是私钥泄露,我对密码学没什么研究不知道这有多大的影响,但是至少我看来及时泄露没有密码的情况下也是白搭,密码还有可能泄露呢何况一个文件

    不知道我的理解对不对:即使我公布我的私钥,在私钥密码非常强大的情况下普通人也没办法很容易破解出来,相当于一个废文件罢了,对于他们得到私钥的人没有任何意义
    ryd994
        86
    ryd994  
       2014 年 9 月 22 日   1
    @SharkIng 也不对,
    比如服务器可以限制穷举频率,banIP等,这是私钥做不到的。但我同意你说的如果私钥正确生成,即使拿到私钥也很难破解 因为私钥是aes加密的。尽管目前证明AES在某些情况下复杂度小于理论值,但增加密钥长度即可。
    私钥登录并不多一个证书,因为即使密码登录,服务器会即时创建一个随机密钥用于通讯,你的密码是在加密通道里传输的。我的理解是:关闭私钥主要是为了防穷举
    我的意见是:如果本地被攻陷,一切白搭。密码私钥唾手可得。所以本地安全是前提,而最安全就是不要root ssh,一个长期稳定运行的系统是不需要很多root操作的,这些操作应该用suid或者有限sudo解决。
    Radeon
        87
    Radeon  
       2014 年 9 月 22 日
    @ryd994

    quote "明白sudo能干啥没?有sudor到某一个用户的权限不代表有sudo到root的权限。
    这样就可以避免私钥随便被拷走了。"

    不懂你在说什么。私钥在终端机上,和服务器上的sudo没有关系
    Radeon
        88
    Radeon  
       2014 年 9 月 22 日
    @ryd994

    quote "比如服务器可以限制穷举频率,banIP等,这是私钥做不到的"

    这就是我说的其他条件一样的情况下,不留下任何硬盘上的可供破解的原始资料更安全。今天你觉得AES是安全的,也许NSA不觉得,或者过了2年AES被曝有重大缺陷怎么办?那时候你的pass phrase保护的密钥早被人拷走了,在你修复漏洞前攻击者先出手了怎么办
    Radeon
        89
    Radeon  
       2014 年 9 月 22 日
    @ryd994

    本地安全根本没有想象中好做到。开发调试阶段开发机往往被用作登陆终端。开发机上安装的软件鱼龙混杂,而且个个能读 ~/.ssh/*。开发机会被带着到处跑,会丢
    ryd994
        90
    ryd994  
       2014 年 9 月 22 日
    @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/*。开发机会被带着到处跑,会丢”

    还是那句话:如果你的管理员连自己电脑安全都无法保证的话,我建议你换个人。专机专用,这是安全的基本
    Radeon
        91
    Radeon  
       2014 年 9 月 22 日
    @ryd994

    我想到另外一个问题:一般人会设定多高强度的pass phrase。如果使用私钥的本意是增加密钥长度,那么使用一个短得多的pass phrase来保护它有什么意义呢?
    ryd994
        92
    ryd994  
       2014 年 9 月 22 日
    @Radeon
    可以用ssh-add管理
    ryd994
        93
    ryd994  
       2014 年 9 月 22 日
    @Radeon 保证密码强度也是管理员安全基本素养之一。
    私钥密码主要还是为了减轻客户机物理接触的危害,比如我上面说的sudo法也无法阻止一个能操作客户机的恶意用户,这个恶意用户不能读取私钥,却可以直接使用,如果没密码就直接能登录了。
    尽管如此,AES也不是吃素的。想穷举私钥成本不小,在发现之前能争取足够的反应时间足矣。
    Radeon
        94
    Radeon  
       2014 年 9 月 22 日
    @ryd994 ssh-add 不过是把pass phrase转移到login password上面,一样是比私钥短得多
    Radeon
        95
    Radeon  
       2014 年 9 月 22 日
    @ryd994 login用户能关掉r权限自然也能开启r权限,不存在只能用私钥不能读的情况
    Radeon
        96
    Radeon  
       2014 年 9 月 22 日
    @ryd994 noligin只是对login/shell有用,写个程序不用shell轻松绕掉
    Radeon
        97
    Radeon  
       2014 年 9 月 22 日
    @ryd994 我总结一下我的观点。任何password及其用加密链保护的变体不能保存在计算机媒介上,写在餐巾纸或者记成口诀、七言绝句都更安全。

    如果一定要保存在计算机媒介上(这时已经败了),加密链上的每个保护密码的强度必须大于被保护对象才有意义
    ryd994
        98
    ryd994  
       2014 年 9 月 22 日 via Android
    @Radeon
    login用户能关掉r权限自然也能开启r权限,不存在只能用私钥不能读的情况
    你看懂我用sudo的作用了么?你只能sudo用,只能ssh用,除非ssh有bug否则安全

    noligin只是对login/shell有用,写个程序不用shell轻松绕掉

    我哪里说过nologin了?停用帐户只有root能解,但可以sudo。
    ryd994
        99
    ryd994  
       2014 年 9 月 22 日 via Android
    @Radeon
    你怎么不说传输时还有破解呢?
    密码会被加密传输,而私钥登录不会,这就是本质上的区别。
    ryd994
        100
    ryd994  
       2014 年 9 月 22 日 via Android
    @Radeon
    如果一定要保存在计算机媒介上(这时已经败了),加密链上的每个保护密码的强度必须大于被保护对象才有意义
    那照你这么说银行的服务器都该砸掉,NSA的服务器都该砸掉了?
    有安全有秘密再正常不过,通过合理的权限管理,安全是可以保证的。如果那么容易就能绕过权限管理,Linux安全组都可以吃屎去了。
    关于     帮助文档     自助推广系统     博客     API     FAQ     Solana     857 人在线   最高记录 6679       Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 144ms UTC 22:19 PVG 06:19 LAX 15:19 JFK 18:19
    Do have faith in what you're doing.
    ubao msn snddm index pchome yahoo rakuten mypaper meadowduck bidyahoo youbao zxmzxm asda bnvcg cvbfg dfscv mmhjk xxddc yybgb zznbn ccubao uaitu acv GXCV ET GDG YH FG BCVB FJFH CBRE CBC GDG ET54 WRWR RWER WREW WRWER RWER SDG EW SF DSFSF fbbs ubao fhd dfg ewr dg df ewwr ewwr et ruyut utut dfg fgd gdfgt etg dfgt dfgd ert4 gd fgg wr 235 wer3 we vsdf sdf gdf ert xcv sdf rwer hfd dfg cvb rwf afb dfh jgh bmn lgh rty gfds cxv xcv xcs vdas fdf fgd cv sdf tert sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf shasha9178 shasha9178 shasha9178 shasha9178 shasha9178 liflif2 liflif2 liflif2 liflif2 liflif2 liblib3 liblib3 liblib3 liblib3 liblib3 zhazha444 zhazha444 zhazha444 zhazha444 zhazha444 dende5 dende denden denden2 denden21 fenfen9 fenf619 fen619 fenfe9 fe619 sdf sdf sdf sdf sdf zhazh90 zhazh0 zhaa50 zha90 zh590 zho zhoz zhozh zhozho zhozho2 lislis lls95 lili95 lils5 liss9 sdf0ty987 sdft876 sdft9876 sdf09876 sd0t9876 sdf0ty98 sdf0976 sdf0ty986 sdf0ty96 sdf0t76 sdf0876 df0ty98 sf0t876 sd0ty76 sdy76 sdf76 sdf0t76 sdf0ty9 sdf0ty98 sdf0ty987 sdf0ty98 sdf6676 sdf876 sd876 sd876 sdf6 sdf6 sdf9876 sdf0t sdf06 sdf0ty9776 sdf0ty9776 sdf0ty76 sdf8876 sdf0t sd6 sdf06 s688876 sd688 sdf86