V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
selfcreditgiving
V2EX  ›  问与答

ssh key 一模一样的设置,另一个就不能 登录是什么原因?

  •  
  •   selfcreditgiving · 39 天前 · 2673 次点击
    这是一个创建于 39 天前的主题,其中的信息可能已经有所发展或是发生改变。

    要用 user1 用户 ssh 登录两台服务器。

    两个服务器,拷贝了相同的公钥:
    /home/user1/.ssh/id_rsa.pub
    和 /home/user1/.ssh/authorized_keys ( id_rsa.pub 拷进来的)
    两个文件的权限都是 700

    /home/user1 文件夹的权限是 600

    id_rsa.pub 、authorized_keys 、/home/user1 的所属用户和所属组都是 user1

    /etc/ssh/sshd_config 设置的也是一模一样的, 也重新启动了 sshd service 。

    为什么一台可以登录,一台就登录不了呢?
    提示这个错误:

    Permission denied (publickey).
    

    每次都被这种东西卡住了,

    /etc/ssh/sshd_config 配置都是这样的:

    # Package generated configuration file
    # See the sshd_config(5) manpage for details
    
    # What ports, IPs and protocols we listen for
    Port 22
    # Use these options to restrict which interfaces/protocols sshd will bind to
    #ListenAddress ::
    #ListenAddress 0.0.0.0
    Protocol 2
    # HostKeys for protocol version 2
    HostKey /etc/ssh/ssh_host_rsa_key
    HostKey /etc/ssh/ssh_host_dsa_key
    HostKey /etc/ssh/ssh_host_ecdsa_key
    HostKey /etc/ssh/ssh_host_ed25519_key
    #Privilege Separation is turned on for security
    UsePrivilegeSeparation no
    
    # Lifetime and size of ephemeral version 1 server key
    KeyRegenerationInterval 3600
    ServerKeyBits 1024
    
    # Logging
    SyslogFacility AUTH
    LogLevel INFO
    
    # Authentication:
    LoginGraceTime 120
    PermitRootLogin no
    StrictModes yes
    
    RSAAuthentication yes
    PubkeyAuthentication yes
    #AuthorizedKeysFile     %h/.ssh/authorized_keys
    
    # Don't read the user's ~/.rhosts and ~/.shosts files
    IgnoreRhosts yes
    # For this to work you will also need host keys in /etc/ssh_known_hosts
    RhostsRSAAuthentication no
    # similar for protocol version 2
    HostbasedAuthentication no
    # Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
    #IgnoreUserKnownHosts yes
    
    # To enable empty passwords, change to yes (NOT RECOMMENDED)
    PermitEmptyPasswords no
    
    # Change to yes to enable challenge-response passwords (beware issues with
    # some PAM modules and threads)
    ChallengeResponseAuthentication no
    
    # Change to no to disable tunnelled clear text passwords
    PasswordAuthentication no
    
    # Kerberos options
    #KerberosAuthentication no
    #KerberosGetAFSToken no
    #KerberosOrLocalPasswd yes
    #KerberosTicketCleanup yes
    
    # GSSAPI options
    #GSSAPIAuthentication no
    #GSSAPICleanupCredentials yes
    
    X11Forwarding yes
    X11DisplayOffset 10
    PrintMotd no
    PrintLastLog yes
    TCPKeepAlive yes
    #UseLogin no
    
    #MaxStartups 10:30:60
    #Banner /etc/issue.net
    
    # Allow client to pass locale environment variables
    AcceptEnv LANG LC_*
    
    Subsystem sftp /usr/lib/openssh/sftp-server
    
    # Set this to 'yes' to enable PAM authentication, account processing,
    # and session processing. If this is enabled, PAM authentication will
    # be allowed through the ChallengeResponseAuthentication and
    # PasswordAuthentication.  Depending on your PAM configuration,
    # PAM authentication via ChallengeResponseAuthentication may bypass
    # the setting of "PermitRootLogin yes
    # If you just want the PAM account and session checks to run without
    # PAM authentication, then enable this but set PasswordAuthentication
    # and ChallengeResponseAuthentication to 'no'.
    UsePAM no                                                                                  
    
    29 条回复    2021-12-21 12:00:21 +08:00
    xiaowei0823
        1
    xiaowei0823  
       39 天前
    ssh -vvv 看一看呢
    Osk
        2
    Osk  
       39 天前
    看看服务端的 sshd 日志. 里面也许有更有用的信息.
    selfcreditgiving
        3
    selfcreditgiving  
    OP
       39 天前
    @Osk ubuntu 的 sshd 日志 是 lastb 嘛?(是一个 ubuntu 的 docker 容器,会不会被精简了就没有日志了)
    而且 lastb 命令提示 没有 /var/log/btmp 文件。 (就是因为这个文件我才要设置 ssh 密钥登录的,一直被暴力破解,一个服务器上大概有十几个 ubuntu 容器,每个容器的 btmp 文件 都有 2 ~ 4G !)
    @xiaowei0823 ssh -v 是 version 嘛, 没有这个 option 提示
    xiaowei0823
        4
    xiaowei0823  
       39 天前
    使用 ssh -vvv 登录服务器的时候会打印详细日志,你两边对比一下看看无法登录的那台服务器卡在哪里了?
    ynyounuo
        5
    ynyounuo  
       39 天前
    @selfcreditgiving
    -v
    Verbose mode. Causes ssh to print debugging messages about its progress. This is helpful in debugging connection, authentication, and configuration problems. Multiple -v options increase the verbosity. The maximum is 3.

    看看 -vvv 应该能很快排查出来
    selfcreditgiving
        6
    selfcreditgiving  
    OP
       39 天前
    Osk
        7
    Osk  
       39 天前
    如果是容器, 日志大概不会是 journalctl 来看.

    尝试 grep -r sshd /var/log
    selfcreditgiving
        8
    selfcreditgiving  
    OP
       39 天前
    服务器 B (失败)

    服务器 A (成功)

    @xiaowei0823 @ynyounuo 请问服务器 B 为什么会找不到 rsa 的 key 呢 ,要去找什么 dsa_key ,都是在我同一个笔记本上操作的
    selfcreditgiving
        9
    selfcreditgiving  
    OP
       39 天前
    十几个容器,加起来 login fail 日志有 40G 了,云盘本来也就 100G 。 真没想到还有这么多的机器人来扫描
    Osk
        10
    Osk  
       39 天前
    看起来是服务端拒绝了 rsa 的那个公钥, 所以 ssh 客户端这边会继续尝试 dsa, ecdsa ed25519 这几个 key 能否登录, 但那几个 key 都不存在.
    而拒绝的原因需要看 b 服务器的 sshd 日志.

    另外, 用公钥登录还是不能彻底杜绝扫描, 每次尝试还是有日志的吧, 要配合 faild2ban, sshguard 等才能挡一下.
    dingwen07
        11
    dingwen07  
       39 天前 via iPhone
    看看 openssh 版本?一般来说能到这也不会有问题
    还得看服务器上的日志
    HXM
        12
    HXM  
       39 天前 via Android
    可以尝试暂时性的把 sshd_config 里 StrictModes 从 yes 改成 no 看看能不能登录,如果这样可以登录的话那就是文件权限问题

    参考来源 https://web.archive.org/web/20140327182105/http://www.openssh.org/faq.html#3.14
    ynyounuo
        13
    ynyounuo  
       39 天前
    估计还是你 server B 上 .ssh/ 的文件夹权限问题,看看是不是 700
    selfcreditgiving
        14
    selfcreditgiving  
    OP
       39 天前
    @HXM @dingwen07 @ynyounuo 好的,我明天再试下看看。

    @Osk 公钥还是会爆日志嘛,linux 开源世界能不能对程序员简单,友好一点呢,,, 来个开箱即用的多好啊。
    不是专门的运维,有没有最少配置的最佳实践呢。 如果说装 vpn 能不能杜绝这种情况?
    Osk
        15
    Osk  
       39 天前   ❤️ 1
    @selfcreditgiving 公钥只是避免别人暴力试出密码, 但它进行中的尝试仍然会继续, 每次尝试都会记录 sshd 日志, 日志仍然会涨.

    ssh 的部分建议:
    不要用默认的 22 端口, 减少一些批量脚本工具有事没事的扫描.
    不要使用密码登录, 而是使用公钥或者两步认证登录, 避免被试出密码进入.
    禁止 root 用户登录.
    限制 sshd 连接数, 但有把自己锁到外边无法登录的风险.
    使用 sshguard, fail2ban 或者端口敲门等办法减少被扫描的次数.


    另外, 建议使用跳板机管理你的服务器: 这样的话, 攻击者首先要破解了跳板机的登录才可以进行后续的扫描, 大大降低了其它生产服务器被 ssh 暴力攻击的次数, 跳板机的 sshd 日志涨就让它涨吧, 反正生产服务器不涨就行.

    当然, 使用 vpn 来保护也是不错的方案, 不过我觉得 vpn 可能也有被扫描的问题, 不如把 sshd 的安全做好.


    至于如何做, 确实没有很统一的做法, linux 发行版间碎片化太严重了, 只能根据你当前的发型版去看官方的 wiki 或者手册.


    另外, windows rdp 3389 更不好搞, 两部认证, 证书登录什么的, 都相当不容易配置, 比 ssh 配置麻烦多了.
    EIlenZe
        16
    EIlenZe  
       39 天前 via iPhone
    @Osk 每次看到这些就会想 要是世界上没有怀有恶意的人 是不是就可以不用做那么多工作了…
    laucenmi
        17
    laucenmi  
       39 天前
    osx 升级 openssh 后遇到过某些服务器不能登录的问题, 在.ssh/config 对 host 添加了
    HostKeyAlgorithms +ssh-rsa
    PubkeyAcceptedKeyTypes +ssh-rsa
    才可以工作.
    selfcreditgiving
        18
    selfcreditgiving  
    OP
       39 天前
    @Osk 多谢说的太详细了!
    还有都配好后,用一个非 root 账户,每次 sudo 要输密码,同时命令前又要加个 sudo ,敲起命令来好累啊
    acmore
        19
    acmore  
       39 天前   ❤️ 1
    @EIlenZe 那么世界上也会失去很多工作岗位(狗头
    dddd1919
        20
    dddd1919  
       39 天前
    兄弟,你私钥呢?
    shangyu7
        21
    shangyu7  
       39 天前
    看看 ssh 版本
    pixelcn
        22
    pixelcn  
       39 天前
    一台是 RPM 系的吧?有 bug
    PubkeyAcceptedKeyTypes 加上 rsa-sha2-512,rsa-sha2-256
    ziseyinzi
        23
    ziseyinzi  
       39 天前
    应该是 17 楼说的,openssh 版本问题。新版本 openssh 因为安全原因会拒绝 rsa 算法的 key 。升级服务端的 openssh 版本或者在本地像 17 楼说的那样添加允许规则。
    ysn2233
        24
    ysn2233  
       39 天前
    高版本的 openssh 加密算法换了,要配置一下
    selfcreditgiving
        25
    selfcreditgiving  
    OP
       38 天前
    抱歉,之前有事情现在才更新。

    这两台服务器 是这样的,都是用 docker 起的 ubuntu 镜像容器,而且镜像是一模一样的。开放出了 ssh 端口。

    这是两台服务器的 openSSH 版本 ssh -V

    服务器 A 和 服务器 B 的结果都是一样的:
    OpenSSH_7.2p2 Ubuntu-4ubuntu2.10, OpenSSL 1.0.2g 1 Mar 2016

    本身操作用的 macbook pro 的 ssh 版本:
    OpenSSH_7.4p1, LibreSSL 2.5.0

    /etc/ssh/sshd_config 两台服务器也是一模一样的。

    @pixelcn @ziseyinzi @ysn2233 在登录失败的 服务器 B 设置了 /etc/ssh/sshd_config ,添加 PubkeyAcceptedKeyTypes rsa-sha2-512,rsa-sha2-256 ,并重启容器(因为 docker 容器里不能 用 service restart )
    结果还是一样的。

    感觉我还是设一个强密码,然后设一个 fail2ban ,可不知道 fail2ban 有没有什么坑,可以设置好就不用管了不?
    selfcreditgiving
        26
    selfcreditgiving  
    OP
       37 天前
    @Osk
    @dddd1919
    @shangyu7
    @pixelcn
    @ziseyinzi
    @ysn2233 发现原因了,又是自己的粗心大意浪费了大量的时间。

    应该是 ~/.ssh 设置为权限 700
    ~/.ssh/authorized_keys 设置为 600

    我设置反了! 想当然 ~/.ssh/authorized_keys 是文件需要 执行权限, ~/.ssh 是文件夹 只要 读写权限就行了。

    后面搜到才发现弄反了。

    server A (成功)是因为 , 没有手动去改 chomd 权限, ~/.ssh/authorized_keys 默认是 644 的权限。


    经常会这样自己搞死自己,浪费大量的时间、熬夜,因为那一块是确认过了的,认为那里肯定是没有问题的,就没想到再去确认一次。大家有没有同样的经历?或者如果规避自己的低级错误导致卡壳的情况?
    selfcreditgiving
        27
    selfcreditgiving  
    OP
       37 天前
    目前找到一个 便利 和 安全 之间相对折中的方法, 就是:所有的服务器都用同一个 ssh 私钥。ssh 私钥设置 passphrase ,并且 passphrase 保存到 macOS 的 keychain (使用 ssh-add -K keyfile )
    ynyounuo
        28
    ynyounuo  
       26 天前   ❤️ 1
    @selfcreditgiving
    #13 我提到过这个问题,如果你当时有查看的话会省很多时间
    selfcreditgiving
        29
    selfcreditgiving  
    OP
       26 天前
    @ynyounuo #28 是的,自己太粗心了,认为这个方面是自己已经知道的,就没有仔细去看是应该文件夹设置 700 。
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2387 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 147ms · UTC 09:48 · PVG 17:48 · LAX 01:48 · JFK 04:48
    ♥ Do have faith in what you're doing.