嗯,最后我还是去广州旅行了,在被称为世界最高城的动漫星城晃悠去了
动漫星城没到点没开门,在外面瞎转悠
然后,看到了有关一个软件的安装教程,想装起来试试
打开 JuiceSSH ,准备登录的时候才想起个问题:这台服务器我关掉了密码登录,只能密钥登录,但是我出门在外,并没有给手机上的 SSH 软件装载私钥
是的,我暂时登录不上这台服务器了
密码登录(或者说,口令登录)的痛点在于容易被人爆破密码,那么如果我设定一个足够强的密码,理论上应该可以大幅度减轻这个问题严重程度?
为了方便记忆和推算,我设想中用的是
k = to_lower(sha256(s))
其中 s 是我记得的一个比较高强度的口令( 14 个字符,大小写特殊符号和数字都有)
当然,我知道,这个做法的安全性,比不上用完一次即失效的『紧急登录刮刮码』
那么问题来了:
谢谢解答
1
vitovan 2023-06-18 10:11:09 +08:00
答不上来。
感觉你已经都懂了。 |
2
dingwen07 2023-06-18 10:15:55 +08:00 via Android 1
我选择直接把私钥放到物理安全密钥里
|
3
tmtstudio 2023-06-18 10:18:16 +08:00
我都是端口指定 IP 访问,用手机的话临时放行一下
|
4
codehz 2023-06-18 10:18:45 +08:00 via iPhone 1
我的建议是,用联网同步的密码管理器(
|
5
geelaw 2023-06-18 10:26:37 +08:00
从密码学角度考虑,口令登录相比密钥登录的问题并不在于“容易被人猜出口令”,而是:(1) 获得一次成功认证过程的明文即可反复重新认证;(2) 服务器被攻击后更容易还原口令。
使用高强度口令可以避免第二个问题,然而我的看法是发送 s 并不比发送 to_lower(sha256(s)) 更糟糕,两者口令的熵是一样的。口令长度不是安全性的源泉,只是代理指标而已,口令强是指它的熵高,而长度和熵的关系是 熵 <= 长度——好的口令一定要长,但长的口令不一定好。 |
6
pluto1 2023-06-18 10:39:46 +08:00 via iPhone
你用 sha256 其实有点类似于最简单的 KDF ,建议看看 scrypt 之类的,感觉理论上安全性可以稍微高一点
|
7
dode 2023-06-18 10:43:17 +08:00
ssh 启用两步验证,然后可以搞几个一次性应急?
|
8
1map 2023-06-18 10:52:25 +08:00
我的密码是派 取前 200 位,每次进入系统都要手动打几分钟,但是安全啊
|
9
mengyx 2023-06-18 10:57:18 +08:00 via Android
建议搞两个安全密钥,随身带着一个;
这之后我就没碰到过类似问题 |
10
caesarding07 2023-06-18 10:59:14 +08:00
我都是用网盘直接存密钥的,用的时候就直接下载密钥。
|
11
mingl0280 2023-06-18 11:03:06 +08:00 via Android
密码越长越好,但是与密码本身使用了多少次不同的字符几乎没有关系。一个 32 个英文字符加几个数字和符号的密码被爆破的难度远高于一个 12 位随机字符串的密码。
|
12
laozhoubuluo 2023-06-18 11:05:14 +08:00
1. 从密码学的角度 hash 算法会降低信息熵,算法套算法可能存在额外的安全隐患(因为算法套算法的安全性大概率没有数学论证也没有专家测试)。但如果只考虑 SSH 暴力破解这一个维度那其实不太好说,毕竟 sha256 里面没有特殊字符但是一般暴力破解也不会考虑 256 位长度。
2. 信息熵的增加一定能增强安全性,甚至不考虑 hash 直接使用 口令+IP 地址 或者 口令+计算机名 的形式都要比只使用口令要安全。 3. 256 位数字+小写字母应该够安全了。 |
13
MoeMoesakura 2023-06-18 11:11:15 +08:00
我反正一直取 uuid 作为密码,爆开还是很难的
|
14
zhleonix 2023-06-18 11:25:34 +08:00
简单数字密码,然后映射到某段经文对应的词(中文的用拼音),很难爆破。
|
15
leaflxh 2023-06-18 12:49:53 +08:00 1
echo dick | sha512sum
be79819833110c0847abb4f6491ccd97daed271e04e6b18d2651a709f65efd1c209c2b94fc2477af34d72968fa0a32e69031ee6bcf6028be59f04971e480689d - |
16
Radeon 2023-06-18 12:58:31 +08:00
k = to_lower(sha256(s))
足够了。这里的关键是输出位数够长就行 |
17
ltkun 2023-06-18 12:58:43 +08:00 via Android
说明你平时没有使用手机登陆服务器的习惯 我基本上大半时间都是手机登陆的
|
18
wangxiaoaer 2023-06-18 13:04:52 +08:00 via iPhone
好家伙,看到紧急登陆还以为又出现什么新技术了呢。
|
20
vain 2023-06-18 13:28:57 +08:00
思路是一样的思路,但是可以用一个更好更容易被记住的方式:
如先设定一个基础密语 S 然后做如下步骤: S1=to_lower(sha256(S)); 取 S1 最后 8 位(或其它位数,自己记住)为 S1.0 然后 S1.1 =S1.0+CurrentDate //比如今天就是在字符串后边加上 6 个字符"20230618",这个日期可以设为每次更改这个密码的时间,只要你在自己的账号记录里记下每次更改密码的日期就行,而且这个信息对不知道的人来说也不知道是 SALT 。 然后 P = to_lower(sha256(S1.1)); 最终密码可以设为 P 的最后 16 位或 24 位字符 //S1.0 的 N 倍,N 你自己心里记住。 基础密语 S 是最关键的,也需要自己记忆,但是有一些好办法,比如用自己才知道的事情做一个提示。 比如下边的例子: “收一台八九成新的 64G 存储的 iPhone 二手手机,有的自己报价,报价请用七个 GB2312 的汉字描述”(这段提示语写在一个地方备忘,甚至可以把它藏在某个过去日期的日记本里,就伪装成过去发过的二手信息的记录,当然你自己要知道去哪里找) 然后密语 S 就是那 7 个指定编码的汉字字符。 |
21
Puteulanus 2023-06-18 13:51:50 +08:00
https://userify.com
以前用过,等于对所有服务器接受的 SSH 公钥进行集中管理,界面有点简陋不过用着还行 |
22
rimutuyuan 2023-06-18 13:54:31 +08:00
把自己的生日 hash 1000 次
|
23
keith1126 2023-06-18 15:12:07 +08:00
obfuscation is not security
用各种奇技淫巧对密码做各种处理,不论是 sha256 还是 base64 ,本质上只是混淆,并不能增加密码的安全性。 但回到问题本身,s 本身已经是高强度密码,所以开心就好……做不做这些都没啥区别 |
24
Maboroshii 2023-06-18 15:25:59 +08:00 via Android
没有人知道你的口令放在哪里,比如,你可以写在鞋垫子上
|
25
TigerK 2023-06-18 15:43:28 +08:00
两步验证吧,就是需要输入一组只有 30 秒有效期的数字作为另一道防线。
|
26
caomingjun 2023-06-18 15:55:26 +08:00 via Android
以我目前的架构,我可以以 yubikey 的 FIDO 加上一段短密码为凭证,向 SSH CA 请求签发有效期两分钟的证书
但是我好像没这种需求 |
27
laqow 2023-06-18 16:10:58 +08:00
会不会给 VPN 设强密码,服务器密码 123456 简单一些?
|
28
rekulas 2023-06-18 16:24:04 +08:00
你感觉 sha256 弱是因为大多是 hex 展示的,本身字符集就只有 16 个同长度自然看起来要弱点,但你完全可以直接用 base64 或者自研 basexxx 算法来映射,安全性就高了
例如我的 vps1 的密码种子是: 黑 5 打折买的廉价美国 vps sha256(hex): e1e2b03f23a306a6104dfa6bd976e365eb553f4d56c33cc867bfadb861705618 sha256(base64): 4eKwPyOjBqYQTfpr2XbjZetVP01WwzzIZ7+tuGFwVhg= 自研映射(base128?): Nz$puJtF7^jKFDy6@m(7-*)... |
29
danhahaha 2023-06-18 16:48:25 +08:00
可以使用一个 [ 固定的复杂密码+当前(月日时分)的时间 ] 组合之后再加密的密码,这样的话,这个密码只有你自己知道,而且任何时候都不一样,强度也足够
|
30
swulling 2023-06-18 16:52:16 +08:00 via iPhone
非要用密码的话,可以用双因素验证。
一个简单的方案就是密码加 google/microsoft 验证器。 |
31
cosette 2023-06-18 17:05:07 +08:00
仅考虑密码口令本身的强度的话,难记的密码强度不一定高,折中的办法是选择 8 个单词配合数字,长度足够长,也容易记忆。
类似于这里的 passphrase 生成方法,多记忆几次就熟悉了。 |
32
cosette 2023-06-18 17:05:55 +08:00
|
33
nznd 2023-06-18 17:09:42 +08:00
为了应对这个情况我做了一个快捷指令可以扫码添加 ssh key (提前把快捷指令的 pub key 添加进去)
|
35
p1gd0g 2023-06-19 10:52:15 +08:00
两步验证不好吗
|
36
lisxour 2023-06-19 10:52:41 +08:00
使用无密码方案
|