V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
wsgzao
V2EX  ›  程序员

SSH 使用密钥登录并禁止口令登录实践

  •  
  •   wsgzao ·
    wsgzao · 2015-07-07 13:38:53 +08:00 · 6124 次点击
    这是一个创建于 3218 天前的主题,其中的信息可能已经有所发展或是发生改变。


    ## 前言
    无论是个人的VPS还是企业允许公网访问的服务器,如果开放22端口的SSH密码登录验证方式,被众多黑客暴力猜解捅破菊花也可能是经常发生的惨剧。企业可以通过防火墙来做限制,普通用户也可能借助修改22端口和强化弱口令等方式防护,但目前相对安全和简单的方案则是让SSH使用密钥登录并禁止口令登录。

    >这是最相对安全的登录管理方式

    ---

    ## 更新历史

    2015年07月07日 - 初稿

    阅读原文 - http://wsgzao.github.io/post/ssh/

    扩展阅读

    - SSH原理与运用 - http://www.ruanyifeng.com/blog/2011/12/ssh_remote_login.html
    - Linode - https://www.linode.com/docs/networking/ssh/use-public-key-authentication-with-ssh
    34 条回复    2015-07-08 14:11:40 +08:00
    realpg
        1
    realpg  
       2015-07-07 13:43:47 +08:00
    技术安全性上用私钥登陆确实安全性比较高
    但是实际场景下,秘钥登陆可能更坑,除非你自己维护就你自己登陆就你自己使用。一个保管不当的秘钥的危害性更大。
    所以一般我都是禁用私钥登陆强制口令登陆的
    onemoo
        2
    onemoo  
       2015-07-07 14:06:01 +08:00
    @realpg 那得保管的多差才能私钥和passphrase一起泄露。如果真的是这么差劲的话,恐怕密码泄露会更容易。
    finian
        3
    finian  
       2015-07-07 14:07:58 +08:00
    @realpg 可以给密钥加 passphrase
    szopen
        4
    szopen  
       2015-07-07 14:50:03 +08:00
    我在考虑一个问题,就是当只能用私钥登录时, 密钥没备份,但是电脑坏了怎么办?
    mongodb
        5
    mongodb  
       2015-07-07 15:00:04 +08:00
    @szopen 没备份这个不能怪别人只能怪自己..
    ryd994
        6
    ryd994  
       2015-07-07 15:04:17 +08:00 via Android
    @szopen 加两个私钥,一个常用一个放u盘应急
    cloverstd
        7
    cloverstd  
       2015-07-07 15:11:00 +08:00 via iPhone
    @szopen 放在网盘或者邮箱
    Tink
        8
    Tink  
       2015-07-07 15:17:20 +08:00
    @szopen 不备份也敢禁用口令登陆?
    szopen
        9
    szopen  
       2015-07-07 15:29:04 +08:00
    林子大了什么情况都能发生
    maxsec
        10
    maxsec  
       2015-07-07 15:33:03 +08:00   ❤️ 1
    楼主敢不敢放一个微信扫描terminal输出的二维码登录ssh的linux组件
    johnsmith123
        11
    johnsmith123  
       2015-07-07 15:40:25 +08:00
    这些和1+1=2 没啥区别(废话)
    AssassinLOVE
        12
    AssassinLOVE  
       2015-07-07 15:45:16 +08:00
    这是新发明?
    abv
        13
    abv  
       2015-07-07 15:52:13 +08:00
    一直用私钥登录,不然每次得输入密码,就是机器变了的话很头疼
    clino
        14
    clino  
       2015-07-07 15:54:24 +08:00
    @szopen 没备份跟忘记密码是一样的下场
    whattheh3ll
        15
    whattheh3ll  
       2015-07-07 15:55:37 +08:00
    我都是禁用 root 登入,其他账号开两步验证。
    nozama
        16
    nozama  
       2015-07-07 16:18:33 +08:00
    万一私钥泄漏, 危及范围就有点广了.
    我的办法是:
    0. 在iCloudDrive保存一个文件.
    1. 每次要用密码, 就用md5 filename生成密码
    2. 用这个密码登录.
    这样就算iCloud泄漏了, 一般也没人知道我是这样生成密码的...
    wsgzao
        17
    wsgzao  
    OP
       2015-07-07 16:31:24 +08:00
    @nozama 私钥一般加passphrase,不用太担心私钥泄露
    Tink
        18
    Tink  
       2015-07-07 16:32:41 +08:00
    @maxsec 好像很不错的主意,偶试试看
    airyland
        19
    airyland  
       2015-07-07 16:41:07 +08:00
    @Tink 期待一下~
    wsgzao
        20
    wsgzao  
    OP
       2015-07-07 16:42:37 +08:00 via Android
    @maxsec 这个方法不错
    kn007
        21
    kn007  
       2015-07-07 16:44:40 +08:00
    需要通过另外一台vps连接主vps ssh,虚假22端口,真正端口放高位。
    kingwrcy
        22
    kingwrcy  
       2015-07-07 17:33:27 +08:00
    如果不是 默认地址 /root/.ssh/id_rsa
    的话,要配置什么?我放在别的地方,然后一样copy到vps,无法登陆,默认位置就可以.
    lilydjwg
        23
    lilydjwg  
       2015-07-07 17:49:35 +08:00
    我的私钥还真泄漏过一次,不小心把私钥当公钥复制给朋友了(所以我有了复制公钥的专用命令)。还好她是可信的,所以我可以慢慢换私钥。

    我的私钥都是没有密码的,累啊。GPG 私钥有密码保护,因为用得少。

    备份当然是有的,和整个系统一起加密备份的。

    密码登陆太累了。而且对于没有安全意识的人你根本没办法。还有人记不住密码所以直接把密码写便笺贴显示器上呢。而且密码很容易被附近的人取得的,偷看不成还能偷听。
    realpg
        24
    realpg  
       2015-07-07 19:32:21 +08:00
    @onemoo
    @finian
    秘钥自然都是有passphrase的,大多数不是泄露的原因,而是透露给了不该透露的人,或者被透露的人应该失去访问权的时候没有失去

    发出去的key,passphrase也没法修改,除非整体在服务器端作废key重发,反倒不如靠一个靠谱密码加上访问策略以及定期更换的制度来的省事

    以上是我的经验,可能不适用所有场合
    RAKE
        25
    RAKE  
       2015-07-07 19:57:01 +08:00
    sshd_config里面有很多措施,比如更改ssh端口,禁止密码,root登录,最大重试次数等。

    @szopen 如果是买的vps的话服务商会有个reset root password的,所以其实最需要注意的地方往往是服务商
    pandada8
        26
    pandada8  
       2015-07-07 20:00:31 +08:00
    开两步验证(
    LazyZhu
        27
    LazyZhu  
       2015-07-07 20:22:44 +08:00
    @realpg
    "发出去的key,passphrase也没法修改,除非整体在服务器端作废key重发,反倒不如靠一个靠谱密码加上访问策略以及定期更换的制度来的省事"
    这句话逻辑有问题哦, 如果是密码作废的话难道修改后不需要重发? 其实你的理由就一个吧,密码比文件的密匙对方便.
    realpg
        28
    realpg  
       2015-07-07 20:43:20 +08:00
    @LazyZhu 密码可以很容易的作废,我们生产服务器的密码是90分钟就作废。

    我们什么套路都用过,使用密码的时期基本没出现过高风险情况,反而是使用私钥的时期出过很多问题。
    当然密码也不是唯一的安全策略,端口号,IP限制,允许访问触发条件都在前面横着呢
    msg7086
        29
    msg7086  
       2015-07-08 02:19:47 +08:00
    @realpg passphrase和key是两回事。
    passphrase相当于把key打包压缩的时候加个rar密码而已。
    要改pass只要拆开然后重新打包加密就好了。
    0bit
        30
    0bit  
       2015-07-08 07:01:58 +08:00
    楼主的教学贴其实不太适合在这里发,能感觉到是在推广自己的博客。但是实际上混这里的有几个人不会配置私钥登录呢。其实直接发个问题讨论比较好。
    onemoo
        31
    onemoo  
       2015-07-08 09:50:20 +08:00
    @realpg 我明白你的意思:被泄露的key的passphrase无法更换。

    不同的管理员一人一账户+key,有个别人的key被泄露的话,更换他的这一个key会比较容易。当然如何得知key被泄露是一个问题!!
    然而我只是觉得“靠谱的密码”的安全风险会更大。可能是使用环境本来就比较安全,所以也没出过问题罢了。


    @maxsec 还是别用微信,自己写个扫码器吧。
    finian
        32
    finian  
       2015-07-08 10:13:45 +08:00
    @realpg 你用密码一样有这样的问题,而且更容易被暴力破解
    realpg
        33
    realpg  
       2015-07-08 10:52:30 +08:00
    @finian 能被暴力破解的密码?如果我们跟NSA或者国安那种大算力杠上了,那我确实承认没办法,日常的密码策略可以保证堆起来的十万的显卡集群在几小时内跑不出来就是了,而且怎么可能允许你多次尝试密码,自然有限制策略的

    @onemoo 不单纯是密码,必然还有一系列登陆策略跟着,关键是真心的,key和pass的原始泄露都不是被人从0开始的获取,都是流程上的漏洞,我们不是那种巨大的大公司什么服务器都是ops来做,一些时候总需要给各个团队开放一些生产服务器的ssh在有审计的情况下让各个团队上去直接操作。
    只要有些人略有恶意,总有办法留下一些key,key很难做到使用一次即废,因为密集的操作这样成本太高,持有key的登陆,都没有多次尝试,在非ssh服务器端的层面,比如iptables等三层链接判断很难进行识别。

    反而是密码,甚至可以用硬件去定期生成,现在我们服务器用的就是这种,密码有效期就是3小时,插在服务器上的一个单片机USB设备提供密码,32位的大小写英文字母数字混合,然后把ubuntu server的任何修改密码的功能都策略性废掉了,你想恢复这些逃不过操作审计,都是一环扣一环的
    cherrot
        34
    cherrot  
       2015-07-08 14:11:40 +08:00
    私钥登录+oath动态token密码验证 噢哈哈
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3101 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 13:44 · PVG 21:44 · LAX 06:44 · JFK 09:44
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.