1. <acronym id='lkn1p'><em id='lkn1p'></em><td id='lkn1p'><div id='lkn1p'></div></td></acronym><address id='lkn1p'><big id='lkn1p'><big id='lkn1p'></big><legend id='lkn1p'></legend></big></address>
      <i id='lkn1p'><div id='lkn1p'><ins id='lkn1p'></ins></div></i>

    2. <tr id='lkn1p'><strong id='lkn1p'></strong><small id='lkn1p'></small><button id='lkn1p'></button><li id='lkn1p'><noscript id='lkn1p'><big id='lkn1p'></big><dt id='lkn1p'></dt></noscript></li></tr><ol id='lkn1p'><table id='lkn1p'><blockquote id='lkn1p'><tbody id='lkn1p'></tbody></blockquote></table></ol><u id='lkn1p'></u><kbd id='lkn1p'><kbd id='lkn1p'></kbd></kbd>
        1. <i id='lkn1p'></i>
          <ins id='lkn1p'></ins>

          <code id='lkn1p'><strong id='lkn1p'></strong></code>
          <fieldset id='lkn1p'></fieldset>
          <dl id='lkn1p'></dl>

            <span id='lkn1p'></span>

            解决linux下set_loginuid failed opening loginuid报错问题

            • 时间:
            • 浏览:12
            • 来源:124软件资讯网

                自从使用php-syslog-ng监控日志信息后  ,经常发现一些已往会忽略的报错信息  ,现在正逐一解决中  。其中一个报错发生在  ,我使用密钥通过ssh上岸到服务器的时间  ,日志信息显示:

                Nov 19 10:32:20 printserver auth 10:32:20 pam_loginuid[9691]: set_loginuid failed opening loginuid

                Nov 19 10:32:20 printserver auth 10:32:20 remote(pam_unix)[9691]: session opened for user root by (uid=0)

                Nov 19 10:32:20 printserver auth 10:32:20 sshd[9689]: Accepted publickey for root from 192.168.228.244 port

                1487 ssh2

                一、缘故原由

                操作系统:红旗DC Server 5.0

                剖析以前的系统日志  ,并没有发现类似的报错信息  ,故嫌疑是最近的操作导致的  。

                从两方面剖析:

                1、openssh-server从4.0p1升级到4.7p1;

                2、使用密钥上岸取代原来的密码上岸方式  。

                先实验用原来的密码方式上岸  ,没有报错;再对比其他机械上原4.0p1版的状态  ,使用密钥上岸 ,也没有报错  。由于我升级openssh-server的时间 ,使用它自带的默认设置文件而非系统4.0p1版的设置  ,故以为报错  ,和设置及使用密钥上岸都有关 。

                二、解决

                经查找资料后测试 ,可通过修改openssh-server的设置文件解决问题 。

                修改/etc/ssh/sshd_config为:

                #ChallengeResponseAuthentication yes

                ChallengeResponseAuthentication no #关闭挑战应答方式

                UsePAM no #不使用PAM认证

                生存后  ,重启sshd服务即可 。

                三、说明

                上述两个参数的说明  ,可从资助文档获得注解:

                # 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 without-password".

                # 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 ,则会凭据ChallengeResponseAuthentication来决议是否使用挑战应答方式(我不知道是否这样翻译)  。而该方式是凭据密码判断的  ,不能和密钥上岸兼容  ,以是会泛起报错  。

                差别的设置  ,可从日志中获得完全差别的效果:

                1、关闭ChallengeResponseAuthentication和打开UsePAM

                使用密钥上岸:

                引用

                Nov 19 10:57:20 printserver auth 10:57:20 sshd(pam_unix)[10322]: session opened for user root by root(uid=0)

                Nov 19 10:57:20 printserver auth 10:57:20 sshd[10320]: Accepted publickey for root from 192.168.228.244 port 1595 ssh2

                2、打开ChallengeResponseAuthentication和UsePAM

                使用密钥上岸就会报错  ,而使用密码上岸是正常的:

                Nov 19 12:23:33 printserver sshd(pam_unix)[24454]: session opened for user root by root(uid=0)

                四、其他

                在Google的时间  ,发现有另外一种解决要领:点击

                就是修改/etc/pam.d/sshd  ,把下面这行注释:

                session required pam_loginuid.so

                不外  ,我在系统中并没有找到这行  。反而  ,从日志可以看到  ,报错是由PAM挪用remote发出的  ,以是  ,我修改/etc/pam.d/remote  ,把这行注释:

                引用

                session required pam_loginuid.so

                这样  ,确认不会再报上面的错误 。但上岸的时间 ,日志就会显示:

                Nov 19 10:06:31 printserver sshd[9582]: Accepted publickey for root from 192.168.228.244

                port 1228 ssh2

                Nov 19 10:06:31 printserver remote(pam_unix)[9584]: session opened for user root by (uid=0)

                Nov 19 10:06:31 login -- root[9584]: ROOT LOGIN ON pts/2 FROM 192.168.228.244

                发出信息的主机从printserver改为login了 ,日志分类会有有错 ,倒霉于使用咯  。

                ◎至于由于焦点没有打开CONFIG_AUDIT功效引起的解决措施

                经确认 ,红旗DC Server 5.0的焦点是已经打开CONFIG_AUDIT的 ,以是  ,解决要领无效  。