我不理解几乎所有 SSH 加固都提到配置公钥 - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Admstor
V2EX    SSH

我不理解几乎所有 SSH 加固都提到配置公钥

  •  
  •   Admstor 14 小时 58 分钟前 3089 次点击
    我理解公钥私钥只是一个更加复杂的密码

    倘若我本身密码就是 16 位以上大小写英文数字符号混合,并且每个服务器密码均随机生成不一样
    并且我开启了 auto-ban 之类的服务,防止穷举猜测密码

    那是否可以认为安全性是接近的
    特别如果是私钥泄露意味你几乎所有服务器等于密码泄露,难道是每个服务器私钥都不一样?
    第 1 条附言    13 小时 36 分钟前
    我发现一些 V2er 总是想当然的嘲讽 16 位密码太弱,但是实际上只计算大小写英文+数字,组合就有 62 的 16 次方,这本身就是天文数字,私钥确实在密码复杂度上更加夸张,但是无论哪一个几乎都可以说在现实中不具备被暴力破解的意义,更多的是出现在密码更加容易泄露,私钥交换过程更安全这样的因素上。

    那么到底为何更安全,也没几个人说得清楚
    89 条回复    2026-02-04 12:04:05 +08:00
    wonderfulcxm
        1
    wonderfulcxm  
       14 小时 50 分钟前 via iPhone   1
    你观察得很仔细,这是个好问题
    jhytxy
        2
    jhytxy  
       14 小时 44 分钟前
    安全性好像并不接近

    但是你的也足够安全,比如你的要破 100 年,私钥的得破 1000 年

    你找 ai 问问密码学的问题吧

    password 和 key
    中文都叫密码,但是意义不同
    laikicka
        3
    laikicka  
       14 小时 42 分钟前   2
    你不懂 SSH 也不懂密码学 是这样的
    zooo
        4
    zooo  
       14 小时 41 分钟前   2
    能在 v 站看到这个帖子我也是开了眼了
    yinmin
        5
    yinmin  
       14 小时 38 分钟前
    私钥文件是可以加密码保护的
    zhy0216
        6
    zhy0216  
       14 小时 38 分钟前 via Android
    好处是本地一个私钥 对多服务器同一个公钥
    万一某个服务器被黑 本地的私钥不用换
    adoal
        7
    adoal  
       14 小时 36 分钟前
    root 帐户用了超级复杂口令
    你自己的登录帐户用了超级复杂口令
    然后你同事那个能 sudo 的帐户用了 admin123
    你配置了口令复杂度的 pam 策略
    然后被所有其它同事一致骂
    xiangyuecn
        8
    xiangyuecn  
       14 小时 28 分钟前
    私钥的“私”,意思是只有你有这个密钥,不会发送出去

    服务器用你的公钥加密的数据只有你能解密,就算是明文传输,也是安全的,任何人截获数据也没用 解密不了,中间人也不好使
    SAFEluren
        9
    SAFEluren  
       14 小时 26 分钟前
    为啥会觉得 16 位混合密码能打得过 rsa or ed25519 呢?那密码就不能泄漏了?
    另外一个人不止可以有一个私钥的,你要是想,当然可以给不同等级的服务器用不同的私钥
    totoro625
        10
    totoro625  
       14 小时 22 分钟前   1
    安全性是接近的
    但是时间线拉长,还是有点差异的
    RSA (4096 位)> Ed25519 > RSA (2048 位)>随机密码

    能理解你不喜欢使用公钥,但是面向所有人的教程:配置公钥,就完事了
    只需要存储一个小文件就 ok ,不需要存储一个特别的“16 位以上大小写英文数字符号混合”
    一个是自己都会记错
    二是会顺手发给微信
    三是人会撒谎
    四是人会犯懒
    wonderfulcxm
        11
    wonderfulcxm  
       14 小时 18 分钟前 via iPhone
    简单地说,Ed25519 密钥拥有 256 bits 的安全性。在数学层面上,破解密钥的难度比破解 16 位密码高出天文数字级。
    wonderfulcxm
        12
    wonderfulcxm  
       14 小时 6 分钟前 via iPhone   1
    主要黑客也要衡量成本,破解难度高就知难而退了,而且公钥挑战失败的错误信息非常明显,不如去祸害别的密码登录的,btw ,fail2ban 这种防不了分布式攻击。如果有几万个 ip ,每个 IP 试一次,也很难将其封锁。
    loading
        13
    loading  
       14 小时 3 分钟前 via Android
    建议先了解一下 PGP ,然后在了解一下公钥交换后,最后看一下你自己提的问题。
    NonResistance
        14
    NonResistance  
       14 小时 1 分钟前 via iPhone
    mercury233
        15
    mercury233  
       14 小时 1 分钟前
    多个复杂密码容易变成防自己,如果在电脑上或者密码管理器中保存密码,泄露风险不比泄露私钥低多少
    nomagick
        16
    nomagick  
       13 小时 57 分钟前
    关键词 DiffieHellman key exchange
    lscho
        17
    lscho  
       13 小时 54 分钟前 via Android
    建议粗略了解一下密码学。。。。在数学层面,安全性是天文数字的差距。
    Admstor
        18
    Admstor  
    OP
       13 小时 46 分钟前
    @adoal 你这个似乎也防不住同事泄露私钥吧
    phrack
        19
    phrack  
       13 小时 44 分钟前   4
    密码登陆的话是密码要发送到 ssh 服务器的,不会像常见的 web 服务那样发送 hash ,可以用 pam 模块拦截记录

    这个知识点估计只有极少数人知道,一般用来后入侵横移

    随机密码你总是要复制粘贴的,剪贴板的内容很容易不小心粘贴到错误的地方,监控剪贴板也比较容易
    Admstor
        20
    Admstor  
    OP
       13 小时 40 分钟前
    @wonderfulcxm 你这个分布式攻击确实,不过 16 位的混合密码,也存在 62 的 16 次方,这个数字也已经是天文数字了,我算了用 10W 设备每秒 100 次尝试,也需要 75 万年,这放到现实其实就是足够安全了吧,更何况这种尝试,我怕是服务器先被流量撑爆
    restkhz
        21
    restkhz  
       13 小时 36 分钟前
    主要是密码管理问题

    比如,服务器有 root 账户,你们几个人一起维护用同一个密码,一旦有人离职这密码就要换掉。但是你现在只需要删掉他公钥就行。就不要说还有那些能 sudo 账户可能还有弱密码的问题...反正直接禁用密码用公钥就没这些事了。

    另外你描述的 16 位密码大概是等效 log2(94)*16 ,105bit 。还是不够长。你要是有 20 位就能做到 128bit 了 XD

    问题是公钥认证模式中几乎不可能做暴力破解。登陆时你要先发你的公钥,你要不先偷到公钥,要不先猜那个巨长的公钥。公钥先猜对了,服务器这时候要你签名之前步骤里的信息,你这才有机会开始猜私钥...

    用密码服务器多了也要用密码管理器...不如用一个公钥私钥对直接解决大部分密码管理问题了。

    另外私钥也可以上密码的。
    artiga033
        22
    artiga033  
       13 小时 33 分钟前 via Android
    考虑实际的话,不管哪种方式要穷举完所有可能先耗尽的可能是网络资源...

    但是有一点是,脑子正常的攻击者遇到没开密码验证的服务器一般就直接放弃尝试了,否则可能会一直试
    Admstor
        23
    Admstor  
    OP
       13 小时 32 分钟前
    @restkhz 你提到的多用户情况确实存在,但这似乎也仅仅是便利性上而非安全性上,更换密码一样安全不是吗? sudo 同理,这已经超过本身讨论,16 位密码是不是足够安全这个范围。

    不论 105bit 还是 128bit 甚至 4096bit ,现实暴力破解的预期时间都可以说是遥遥无期
    Admstor
        24
    Admstor  
    OP
       13 小时 29 分钟前
    @artiga033 一直尝试绝大部分情况下也并不会导致网络阻塞,毕竟想阻塞网络不会用尝试 SSH 密码这种攻击方式。还是回到密码本身是否足够安全这样的范围里讨论吧
    wonderfulcxm
        25
    wonderfulcxm  
       13 小时 27 分钟前 via iPhone
    @Admstor 如果从负载的角度看,更应该关闭密码验证只启用密钥,每次密码验证服务器要进行一次复杂的哈希运算,这些还故意设计得很慢,需要消耗大量内存,而公钥验证速度极快,对内存要求也很低。
    01802
        26
    01802  
       13 小时 12 分钟前 via Android
    和密码是两种东西啊,记得三十年前老师专门讲公钥私钥在邮件加密里的作用。
    BenHunDun
        27
    BenHunDun  
       13 小时 7 分钟前
    @Admstor 公私钥本质就不是说类似做密码验证. 可能先了解一下对称加密, 非对称加密.
    像是你一直提到的是密码比对, 但是如果在传输不可信的时候. 他可能就会出问题, 类似中间人攻击.
    (叠个甲. 对安全这块个人也不是专业的) 上面的这些内容可以了解一下.
    adoal
        28
    adoal  
       13 小时 5 分钟前
    @Admstor 能防住用了 admin123 当口令还不觉得是问题的同事
    adoal
        29
    adoal  
       13 小时 4 分钟前
    @totoro625 对,OP 的想法太考验人性了
    BenHunDun
        30
    BenHunDun  
       13 小时 3 分钟前
    然后泄露凭证, 密码, 公私钥这类, 应该都不属于密码学和网络协议能够解决的范畴
    adoal
        31
    adoal  
       12 小时 59 分钟前
    算了,还是放弃吧、OP 说的对 o()o
    aarontian
        32
    aarontian  
       12 小时 58 分钟前
    私钥的永远不会离开你的电脑,由此可以避免中间人攻击,重放攻击,撞库攻击等(我觉得这是最主要优势)。密码简单的容易破解,复杂的你需要备份/复制粘贴,再敲键盘,每一步都会增加危险。

    私钥没有任何语义特征,密码通常有(如果你想记住),这是天然的不安全性。

    特殊情况下你的服务器被侵入,如果是密码加密,攻击者可以对 hash 进行离线脱机爆破,这个过程只需要简单的位运算 一块 RTX 4090 跑 SHA-256 的速度大约是 100 GH/s (10^{11} 次/秒)。而破解 ed25519 尝试一次的运算成本是哈希运算的数万倍。

    公共服务器的登陆管理就不说了。

    如果考虑未来的技术(量子计算),这个差距会发生反转:
    破解密码: 使用 Grover 算法,复杂度从 2^n 变为 \sqrt{2^n}。即 2^{128} 变成 2^{64}。虽然变弱了,但 2^{64} 依然是一个非常高的门槛。
    破解密钥: 使用 Shor 算法,Ed25519 这种非对称加密会被彻底攻破(复杂度变为多项式级 O(n^3))。

    AI 回答,供参考
    ronman
        33
    ronman  
       12 小时 51 分钟前
    现在这个背景下,这种话题和 ai 讨论,没必要发帖
    Overfill3641
        34
    Overfill3641  
       12 小时 46 分钟前   2
    开密码,一堆 IP 在那尝试破解,你越 BAN 对方越起劲。
    用密钥,对方尝试下就不鸟你了。
    moudy
        35
    moudy  
       12 小时 29 分钟前 via iPhone
    @Admstor 信息安全是一个体系,不光是密码复杂度这一项指标。密钥管理,算法,日常安全更新频率,加密流程都会影响整体安全性。
    liuzimin
        36
    liuzimin  
       12 小时 24 分钟前 via Android
    为啥没人提 2FA ?我给 ssh 加了个 OTP 的 2FA ,感觉很安心。而且也带多次输错自动 BAN 一段时间的功能。
    psllll
        37
    psllll  
       12 小时 12 分钟前
    记性差的话开了 auto-ban 基本上都是挡自己,自己还得去服务商面板那里解除
    GoldenSheep
        38
    GoldenSheep  
       11 小时 8 分钟前
    我用 ssh-agent,私钥从不落盘
    restkhz
        39
    restkhz  
       10 小时 59 分钟前
    @Admstor OK, 你想谈安全。
    你要从抵抗暴力破解来说,你这种情况完全足够了。非常安全。

    但是!

    从设计思路上来说,“口令”这种东西就是要给对方进行验证的。你有 secret,我也有,我要给你看 secret 来证明我有。两端都一定会要存有 secret ,并且在验证的时候这个 secret 一定会被传输。
    公钥认证的思路是我们 secret 从不离开自己的设备。只要做一次 challenge-response 证明你有 secret 就可以. 我们只是用 secret 签名,secret 不会被传输,甚至服务器上都不需要存有 secret 存在.

    你觉得哪种设计更安全?以后能暴露的攻击面更少?

    你的对手会的不只是暴力破解。secret 出现的地方越多,出问题的可能性越大。我理解你讲的比如如果我密码足够强就算黑客读到/etc/shadow 也破不出来,和黑客拿到公钥没用同理。然而一旦出现 secret 明文本身呢?楼上也有说到 PAM 模块直接拦截读取明文的,这就是问题。但是我们或许应该在一开始就直接掐死这种可能。只要 secret 压根不出现在服务器上,不被传输,就没这些事情了。



    我们抛开上面的理论层面的东西,
    在现实世界中,合理的密码的确足够强。我自己也有不少设备和 VM 都是用密码的。小规模使用其实不会有任何问题,这也是为什么他至今都存在。
    问题就是它经常被不合理使用,而且随着规模的扩大它只会越来越不方便。所以到一定规模的时候,我认为,使用公钥的最大原因就是:方便管理

    安全这种东西你永远不能指望用户。用户是可以用 123456 作为密码的,是可以为了看毛片随手运行 exe 并且卸载杀毒软件的。更不要说定期更换密码,16 位大小写数字符号组合。所以不如直接逼着用户用更复杂的一套算了。


    所以回到问题本身,我觉得公钥的确是更安全的,从理论和应用上都是。我希望我说清楚了。


    顺便我在某个实验室做运维,管理 100+的 OS ,你猜猜我们用什么做 SSH 验证?密码?公钥?





    答案:都不是,我们用 kerberos
    kerberos 就更安全吗?没有。单纯就是管理方便。

    安全不安全,你得带着威胁模型再讨论。在你提出的问题中,如果仅考虑暴力等等的,你这的确安全。
    但是考虑防御纵深,那就不如公钥那么安全。就这样。管理也没那么方便。
    ryd994
        40
    ryd994  
       8 小时 22 分钟前 via Android
    “只计算大小写英文+数字,组合就有 62 的 16 次方”
    我不信你能记住任意 16 位纯随机密码。人能记住的信息量是有限的。你的 16 位密码大概率是包含了方便记忆的单词或者数字(比如日期),这些都会被优先穷举。
    记不住怎么办?大部分人都会偷偷用笔记下来或者记在手机里,这就非常不安全。这一点对于多人访问的项目来说非常重要,因为你不能指望所有人都和你一样记性好。

    ssh 密钥文件存在电脑里的话,那和 ssh 密码写下来一样不安全。但是 ssh 密钥还可以放到硬件密钥里,无法读取,只能用于握手。这就安全了百倍。

    其次,密钥认证可以防止蜜罐。如果你有一台服务器被植入病毒。病毒完全可以修改 ssh 登入程序,偷偷记录密码,然后到你其他服务器上使用。但是密钥认证全程不传输密钥本身。密钥只是用来签名握手数据。

    总之,密钥认证不仅更安全,还更方便。我反正是不可能背 64 位纯随机密码的。你爱背你背。
    NonResistance
        41
    NonResistance  
       7 小时 54 分钟前 via iPhone
    op 认为 16<4096
    allplay
        42
    allplay  
       7 小时 7 分钟前 via Android
    前面有人提到了密钥交换过程,怕楼主还没明白,再解释一下:
    比如服务器是一个 http 协议的网页,你在上面输密码,密码明文传输过去,那这整个过程所有人都能看见。
    为了保护这个输密码的过程,以及所有的数据传输,现在都用 HTTPS ,这个 HTTPS 本来就是公钥私钥体体制的呀。
    这道理明白吧。

    不仅登录要认证,传输内容也要加密。

    ssh 同理,是先建立公钥交换的加密隧道,然后才给你输入密码的机会。你第一次登录服务器的时候,在输入密码之前,是不是有个问你是否信任服务器指纹的选项? yes no ?这就是服务器的公钥!
    所以公钥机制你是回避不了的。
    GeruzoniAnsasu
        43
    GeruzoniAnsasu  
       7 小时 2 分钟前   1
    密码:你先告诉我秘密以便证明身份
    非对称加密体系: 我**不需要告知任何秘密**就能证明我的身份
    allplay
        44
    allplay  
       6 小时 59 分钟前 via Android
    我理解公钥私钥只是一个更加复杂的密码
    -
    你这个理解从根本上是错误的。
    公钥私钥的本意是解决加密通信密钥传输问题的。你登录服务器时,如果没有公钥首先建立加密通道(用户无感,所以你不知道)的话,那么你输入密码这个过程,本身就立马暴露了。
    allplay
        45
    allplay  
       6 小时 51 分钟前 via Android
    如果没有公钥,你输入的密码必须明文传输给服务器,那么这时候,从你家出去,在几百公里的线路上,经过 n 个交换机路由器,任何人都可以大摇大摆地窃听你传的那一段你以为很强的!多位的明文是什么。可笑不。

    从历史上,在公钥体系建立起起之前,商业信函的很大一部分是在分发密钥,纸质打印的密码。这样才能安全地(彻底安全吗?)把密码告诉对方。
    szdosar
        46
    szdosar  
       6 小时 21 分钟前 via iPhone
    密码难不难猜,只是是否 [安全] 的衡量标准其中之一。同时还有管理便捷和易实现性,也是很重要的安全考量指标之一。每换一个密码,成本太高,要公告所有应该知道密码的人
    aulayli
        47
    aulayli  
       6 小时 13 分钟前 via Android
    那我问你,你用复杂的长密码你记的住吗?如果记不住你是不是要把密码保存哪里?复杂的长密码你能保证每次都手动输入不用复制粘贴吗?密码验证的原理还需要把密码发送到服务器进行验证,这些环节是不是增加了很多泄露的风险。

    使用密钥就没有这些烦恼了,密钥有公钥和私钥,只有公钥需要上传到服务器,就算你把公钥公开到全网也没关系,因为私钥文件永远存放在你本地,密钥也不会上传到远程服务器,只是用来加密消息,你的公钥加密的信息只有你的私钥能解开,你的私钥加密的信息也只有你的公钥能验证是否来自于你本人,跟密码相比这样是不是更方便更安全。
    laminux29
        48
    laminux29  
       4 小时 49 分钟前
    专业的来解释一下:

    1.公钥私钥只是一个更加复杂的密码:√

    2.倘若本身密码就是 16 位以上大小写英文数字符号混合 + 每个服务器密码均随机生成不一样 + auto-ban 之类的服务,防止穷举猜测密码,安全性是接近的:√

    3.如果是私钥泄露意味你几乎所有服务器等于密码泄露:√

    4.难道是每个服务器私钥都不一样:这样看管理员的纪律性。纪律性强就可以每台服务器都给一个独立的私钥。

    另外再回答一下关键问题,为什么业界鼓吹证书,为什么业界会觉得密码不安全?其实是管理问题。

    因为你可能没见过,以前有太多的服务器的管理员密码居然是 123456 ,以及共享管道根本就没加密。后来国家出台等保制度后,仍然有大量密码是
    qQ_@#!2008
    这种假的复杂密码。用证书等于是强制避免管理员偷懒,等于是强制他们使用高级复杂密码。
    rrfeng
        49
    rrfeng  
       4 小时 20 分钟前
    密码属于:what you know
    私钥属于:what you have

    本质上都不是一种东西。

    比较容易理解的区别是:密码你要发送到服务器去验证,私钥永远不会出现在网络上(只需要在本地完成 challenge )。

    「反正 SSH 通道已经是加密过了,发送密码也是安全的」:这个是传输安全,不是认证因素的安全,根本不是一码事。不能把 A 的安全性建立在 B 之上。
    v1
        50
    v1  
       4 小时 19 分钟前
    建议了解下 kms ( Key Management Service ),不是巨硬的 kms ,用密码行吗
    ryd994
        51
    ryd994  
       4 小时 13 分钟前 via Android
    @allplay #44 你的理解也不全面
    ssh 每次会话都会协商一个新的对称密钥用于数据传输。这一点和 TLS 一样。

    ssh 的公钥认证仅仅用于身份认证。同样的,为了避免中间人攻击,服务器也有一对公钥给客户端认证。如果你有其它渠道传输的话,可以预先获取服务器公钥,而不是在第一次访问服务器时信任服务器提供的公钥。

    不需要公钥加密也可以建立加密信道,TLS 用的是 DH 交换。但是不认证身份的话,仅凭 DH 交换无法防止中间人攻击。

    @NonResistance #41 准确的说是 16*7=112bit 。当然和 4096bit 还是差很远的。
    其次这是鸡同鸭讲。不同算法之间不能直接比较密钥位数。因为穷举的复杂度不一样。比如现在就流行用 ecdsa 密钥,几百位的 ecdsa 就可以对等到几千位的 RSA 密钥的安全性。
    对于 ssh 密码,重点是一次尝试的成本。如果用 fail2ban 的话这个成本可以做到很高。所以楼主这个逻辑倒也不完全错。




    @laminux29 #48 似乎并不是非常专业。也许你是安全业内人士。但是显然你对密码学和网络协议的了解很有限。公钥认证和密码认证的本质区别在于公钥认证不传输私钥。而密码认证要传输密码(虽然经过加密,但服务器也可以解密)。
    laminux29
        52
    laminux29  
       3 小时 57 分钟前
    @ryd994 你对公钥认证与密码认证的本质理解,只是停留在书面上。

    两者都是认证,传输的也都是语义上的“算力证据”。只是目前算力有限,导致两种认证方式的“算力证据”的破解难度出现量级差别,才让初学者认为这两种体系不一样。当算力爆发后,甚至出现在固定数量的普朗克时间内能对 NP 问题给出确定解的硬件,破解这两种认证的“算力证据”的时间会趋同且都极短,那时初学者才能看明白这两种认证方式的共性。
    wy315700
        53
    wy315700  
       3 小时 34 分钟前   1
    难道是每个服务器私钥都不一样


    答对了。



    公钥系统的标准部署方案就是,私钥不出机器。

    每台机器各自产生自己的私钥,并且相互交换公钥,或者给公钥颁发证书。

    而不是在一台机器上生成私钥,然后复制到其他机器。
    NonResistance
        54
    NonResistance  
       3 小时 31 分钟前 via iPhone
    @ryd994 op 说的又不是 ecdsa ,没必要扯东扯西,bits 不能直接代表安全性这个谁都懂
    wy315700
        55
    wy315700  
       3 小时 28 分钟前
    再举个例子吧。

    如果你用密码登录的时候由于某些原因(被劫持或者输错了),尝试去登录了别的服务器,那么你的密码就会被别的服务器知道,而用密钥就可以避免这个问题。




    因为

    密码 本质上是对称加密。

    而密钥,是非对称加密。

    用非对称加密建立连接,然后随机产生对称密钥加密传输后续的流量,是当前的主流做法。
    evill
        56
    evill  
       3 小时 25 分钟前
    随机密码?我只有一个问题几千台服务器怎么办?
    villivateur
        57
    villivateur  
       3 小时 24 分钟前
    因为配置公钥最简单啊,你每次登录都要输一长串密码不烦吗?
    evill
        58
    evill  
       3 小时 24 分钟前
    还有一个问题,有一个人管理几千台中的几百台,然后离职了怎么办?

    ssh cert 的是吊销的,难道去重置所有密码?
    bobryjosin
        59
    bobryjosin  
       3 小时 15 分钟前 via iPhone
    密码通过穷举确实攻破概率极低,除非密码记录在纸上记在脑袋里每次手动敲一遍,就算这样你也防不了密码被键盘记录器记录,本地文件被拖这种情况

    楼上也说了私钥也可以是用密码保护的,除了密码保护还有-sk 类型的密钥对,私钥直接不出去的,生成签名验证也完全在安全元件里面进行,也就根本涉及不到私钥泄漏这个问题,除非攻击者直接进你家拿走安全密钥并强制让你说出 pin ,或者安全元件本身有漏洞,当然这种情况用什么也不好使
    dog82
        60
    dog82  
       3 小时 13 分钟前
    2fa 最好。公钥-私钥本质是也是个密码,而且必须得以某种形式存在硬盘上
    june4
        61
    june4  
       3 小时 8 分钟前
    配置这么长的符合最大安全规范随机密码,这不就是要手动输的密钥吗?所以你理解不了为什么要自动化这个过程?
    Dkngit
        62
    Dkngit  
       3 小时 8 分钟前
    问各位大佬,我现在的 VPS 仅有 root ,当前为密码验证。我若改为 ssh-key 认证,需要另建 sudo 用户设置 key ,然后将 root 禁用登录吗?还是给 root 设置 ssh-key 就行了
    ryd994
        63
    ryd994  
       3 小时 1 分钟前 via Android
    @laminux29 区别是协议上的使用方法。如果服务器被做了蜜罐,或者被中间人。那么密码认证是瞬间沦陷,因为它对于服务器来说是明文。而公钥加密的难度则大得多。这对于多台服务器之间是非常有意义的。

    举个现实的例子:如果我朋友需要我暂时帮忙解决一个小问题,我可以闭着眼睛把我的公钥给他,甚至可以全网公开。不开玩笑,我的 ssh 公钥就在 github 公开,这是公开的 API: https://github.com/<username>.keys

    密码认证能做到吗?就算开个管理员用户给 sudo 权限,朋友也必须给我生成一个随机的密码,并用安全的渠道发送给我。

    “当算力爆发后,甚至出现在固定数量的普朗克时间内能对 NP 问题给出确定解的硬件,破解这两种认证的“算力证据”的时间会趋同且都极短”
    什么时候有再说吧。连威胁模型都没定义就讨论极限情况,这才是典型的初学者的误区。你怎么不直接假设天顶星科技可以远程读心?
    loading
        64
    loading  
       3 小时 1 分钟前 via Android
    举个例子吧:

    你和两个朋友在玩一个游戏,规则是三个人面对面大声说话,朋友 A 要告诉你一个秘密,只能大声密谋,他如何告诉你。

    你可能想到,A 可以用只有你俩知道的事加密,这可以做到,但想加密任何内容比较麻烦而且你无法确认你俩的这个秘密是否已经被 B 知道。

    现在请非对称加密算法登场。

    你马上生成一对公私钥,大声说出公钥,A 和 B 同时都能听到。(大声密谋)

    如果有必要,再大声说出并解析清楚这个算法。(对,完全开源,就是这么牛,你看以前谍战片能这样?)

    然后 A 用你这个算法加你俩的秘密,然后将加密后的密文大声说出来,这时,B 也能听到。

    厉害的来了。

    B 无法解密。
    你,用刚才你生成的私钥,能解出来。
    补充一下,A 也无法解密,哈,当然,他自己有原文。

    以上就是大声密谋!


    如果 B 给你说的是他这边生成的公钥,后面你们通话就都能是密文了,而且就你俩能解开。



    如果这个场景你们是通过打电话做的,如果在刚开始的时候,电话线被剪断了。C 在中间给你假装他是 A ,给 A 假装他是你,他给了他的公钥给 A ,然后一直假装,这就叫中间人攻击了。

    为了防止这个事,就出现根证书,有一个内置或者其他方式建立的信任树,你可以理解为熟人当面介绍。

    大概这么多,不正之处请各位雅正。
    ShinichiYao
        65
    ShinichiYao  
       2 小时 57 分钟前
    密钥是比密码安全,但是确实没密码方便,密码可以记在脑子里,密钥得有储存介质
    jadeborner
        66
    jadeborner  
       2 小时 50 分钟前
    最大区别是攻击者不太可能获取到你的私钥,但是密码的哈希值是保存在服务器上的。
    另外私钥可以加 passkey ,你不会不知道吧。就算你获得了我的私钥,你依然要输入密码。
    Fish1024
        67
    Fish1024  
       2 小时 46 分钟前
    除了安全性,还有便利性。
    用密钥,我可以给一个用户添加多个公钥。比如要给别人临时用下,把他的公钥添加到 .ssh/authorized_keys 中就行了,不给他用了,删掉他的公钥就行。不用泄漏我的密码。
    对于多个人同时用的情况下,便利性会更高,不用用完了改密码再通知每个人。
    如果只是你自己用,那长密码的安全性的确是足够了。
    ryd994
        68
    ryd994  
       2 小时 45 分钟前 via Android
    @ShinichiYao 我的个人服务器会用 cloudflare tunnel 。这个认证模型基于 KPI 。服务器上只配置信任一个 CA 。cloudflare 会每次生成一个一次性的客户端证书,由 CA 签名。服务器验证签名的有效性。

    优点是只需要用 oauth 网页认证,比如我用的是 Google 账号,之后也是网页访问,连 ssh 客户端都可以不用。其次端口完全不需要暴露到公网,因为 cloudflared 是本地连接。我的很多虚拟机连公网 IP 都没有。

    其实正规企业部署服务器都是用跳板机,配合 JIT 提权。证书认证是基础,密码认证就更不可能了。
    spadger
        69
    spadger  
       2 小时 44 分钟前
    这样说,不管好不好用,显得自己很“专业”啊
    ryd994
        70
    ryd994  
       2 小时 42 分钟前 via Android
    @jadeborner #66 不要依赖私钥的本地加密。那个加密只是对称加密算法。如果我没记错的话好像是 3DES ,PIN 位数不多的话基本和没有一样。
    如果你认真要用的话肯定要用智能卡/硬件密钥/TPM 。输错 PIN 会自毁,所以 PIN 可以很简单,只要别人前 X 次猜不到就可以了。
    willamtang
        71
    willamtang  
       2 小时 35 分钟前
    面对 mitm 的时候,效果有很大差别
    henix
        72
    henix  
       2 小时 22 分钟前
    > 我理解公钥私钥只是一个更加复杂的密码
    不同意,我认为关键是不同的认证协议带来的攻击面不同:
    你所谓的密码,通过发送给服务器验证身份,这个网络通信过程中的每一个节点(中间的路由器)都可能读取到这个信息
    而公钥加密体系用的 DiffieHellman 密钥交换算法,你完全不发送私钥的信息,或者说通过数学保证发送的信息不足以反推出私钥本身
    那么私钥的泄露途径就只可能是你自己的电脑中木马
    而密码的泄露途径可能是中间的任何网络节点(包括你的服务器)
    woniu7
        73
    woniu7  
       2 小时 5 分钟前
    不是哥们,私钥泄漏是你自己的问题,否则他永远不会暴露在传输信道,公共服务器上,也几乎无法逆向得出私钥。
    密码你不得发出去的吗??你怎么保证不被截获泄漏,
    哦因为加密的?那用啥加密传的密码??不是还是公私钥吗,你那是密码传输安全吗,那是公私钥的功劳。
    diudiuu
        74
    diudiuu  
       2 小时前
    @wy315700 服务器上的是公钥 - -,但是不影响理解.
    op 估计想说的是,这个密码对于用的人来说 16 为随机和秘钥没有区别,因为就是一个配置问题,但是设计上使用一定会用秘钥的.
    我这边经常遇到公司内部有人把代码不小心上传到自己 github 上,仓库还是 public,我们全部用的都是秘钥,我干的最多的就是有人干一次,整个项目三天内都要更换麻烦死了.都骂了不止一次这种人了
    hefish
        75
    hefish  
       1 小时 55 分钟前
    op 继续用密码就是了,我不强制。
    AoEiuV020JP
        76
    AoEiuV020JP  
       1 小时 45 分钟前
    的确和长度有关,
    一般来说 rsa 密钥 1024 位已经被认为太短了不够安全了,
    而你 16 字符的密码就觉得已经很长了,那要你记 40 字符的密码岂不是要命了,
    Huelse
        77
    Huelse  
       1 小时 38 分钟前
    不允许密码登录就筛选掉了一大批人,跟你密码长度无关
    不信你开个默认 22 端口的密码登录,没几天就是一堆尝试登录的日志
    laminux29
        78
    laminux29  
       1 小时 37 分钟前
    @ryd994

    如果服务器被做了蜜罐,或者被中间人。那么密码认证是瞬间沦陷
    =============
    如果服务器被做了蜜罐,或者被中间人,那么服务器已经沦陷了。此时用什么方式认证已经不值得讨论。


    这对于多台服务器之间是非常有意义的
    =============
    我在前面说了纪律性问题与每台服务器应配置独立私钥或密码。


    举个现实的例子:如果我朋友需要我暂时帮忙解决一个小问题,我可以闭着眼睛把我的公钥给他,甚至可以全网公开。不开玩笑,我的 ssh 公钥就在 github 公开,这是公开的 API: https://github.com/<username>.keys
    密码认证能做到吗?就算开个管理员用户给 sudo 权限,朋友也必须给我生成一个随机的密码,并用安全的渠道发送给我。
    =============
    你想跳楼没人拦你。但如果你在工作与生产环境这么做,那就是玩忽职守了,情节严重时可能会坐牢。


    “当算力爆发后,甚至出现在固定数量的普朗克时间内能对 NP 问题给出确定解的硬件,破解这两种认证的“算力证据”的时间会趋同且都极短”
    什么时候有再说吧。连威胁模型都没定义就讨论极限情况,这才是典型的初学者的误区。你怎么不直接假设天顶星科技可以远程读心?
    =============
    威胁模型其实已经说了:算力威胁。不认真看文字,这才是典型的初学者的误区。
    killerv
        79
    killerv  
       1 小时 36 分钟前
    唉,这里面涉及到很多东西,你理解的太浅了,甚至无从谈起,随便说两点

    密码认证等于服务暴露,给了暴力尝试的机会,你的 auto-ban 也只是事后。而密钥认证,攻击者发起暴力尝试的资格都没有,他没有公钥,连私钥签名验证的机会都没有,这是巨大的成本提升。只要看到服务器禁止密码登录,攻击者几乎都会放弃。
    密码认证,是会存在很多暴露机会的,粘贴板、网络等等,而密钥认证,私钥从始至终没有离开过你的设备,在使用过程中几乎没有泄露的风险。
    你提到私钥泄露,这是个伪命题。而且相比密码使用的过程,密码泄露的风险远大于私钥。
    cloudzhou
        80
    cloudzhou  
       1 小时 23 分钟前
    这时候就体现出 ai 在学习方面的重要性了,虽然我知道 ssh 公钥肯定更安全

    https://gemini.google.com/share/0df3fc640c08
    wy315700
        81
    wy315700  
       1 小时 22 分钟前
    @diudiuu
    我指的是有多台服务器要相互通讯的,就会各自建立私钥,然后分享公钥,而不是用同一个密码。


    至于公司内部有人把代码不小心上传到自己 github 上,,那就是密钥管理的问题了,密钥不应该出现在代码里。。
    M9jB6pg65
        82
    M9jB6pg65  
       1 小时 5 分钟前
    @rrfeng 说的好,我再补充一下, 还有最关键的密码分发渠道也是不安全的, 实践中运维分发密码给用户这个渠道是有可能被窃听的, 而用户发送公钥给运维就算被窃听也不影响安全性
    allplay
        83
    allplay  
       53 分钟前 via Android
    op 主现在理解了吗。服气了不?
    fregie
        84
    fregie  
       49 分钟前
    安全性也不能只纯加密维度的安全性,人才是最大的漏洞
    在考虑安全性问题时,更不能只考虑理想情况和正常情况,而是要着重考虑最差情况
    服务器管理上难免出现给另一个人权限的场景,就避免不了线上发送一些凭证,公钥在网络上发来发去可比密码发来去安全太多了
    p1gd0g
        85
    p1gd0g  
       44 分钟前
    不是一个技术路线,非对称加密可不只是为了安全
    vishun
        86
    vishun  
       39 分钟前
    @restkhz 没明白离职删除公钥怎么就更方便管理?有多个公钥,这不是和有多个密码一样吗?和离职删除用户有什么区别?
    anntt
        87
    anntt  
       35 分钟前 via iPhone
    SSH 的明文密码是有几率被拦截到的,背后是一系列技术手段,但通过公钥推导出私钥是不可能的,也几乎不可嗅探。 当然你本机被黑就另当别论。 你可以继续相信你相信的,安全行业发展出这么多新的安全技术,都有它的道理。
    allplay
        88
    allplay  
       28 分钟前 via Android
    op:私钥交换过程更安全这样的因素上。
    -
    大错特错,私钥是不交换的。只传递了公钥。
    ryd994
        89
    ryd994  
       6 分钟前 via Android
    @laminux29 #78 “每台服务器应配置独立私钥或密码”
    你做得到你牛逼。我无话可说。一机一密就算高安全了?高安全至少应该是堡垒机带审计+JIT 限时授权。你都做得到一机一密和分发密码了,所需的基础设施完全可以做到上面两个。你的一机一密不会是记事本吧?不会吧不会吧?
    我在大厂工作,没吃过猪肉还是见过猪跑的。访问生产环境的账号就是禁用密码登入,我也从来都不知道密码。只允许物理密钥的证书登入。
    16 位密码,还一机一密,谁爱背谁背,你背的下来你牛逼,我反正不背。

    “威胁模型其实已经说了:算力威胁”
    啊对对对,别人说防弹衣可以防弹。你直接掏出一把 RPG 把防弹衣炸了,看来防弹衣穿不穿没区别。
    讨论一个尚不存在的技术有什么意义吗?至少不是普通黑客可以接触得到的技术。我认为这个帖子的威胁模型至少应该是目前互联网上常见的攻击途径。比如 ssh 穷举,比如其它服务提权漏洞被入侵后挂马,这都是已经发生过而且一定会继续发生的。
    你考虑量子计算机不如先考虑考虑 CIA 往开源加密算法/软件里放后门。这倒是真的发生过而且完全有可能继续发生的。
    关于     帮助文档     自助推广系统     博客     API     FAQ     Solana     3367 人在线   最高记录 6679       Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 67ms UTC 04:10 PVG 12:10 LAX 20:10 JFK 23:10
    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