<code id='jpfnm'><strong id='jpfnm'></strong></code>
    <dl id='jpfnm'></dl>

  1. <acronym id='jpfnm'><em id='jpfnm'></em><td id='jpfnm'><div id='jpfnm'></div></td></acronym><address id='jpfnm'><big id='jpfnm'><big id='jpfnm'></big><legend id='jpfnm'></legend></big></address>
      1. <tr id='jpfnm'><strong id='jpfnm'></strong><small id='jpfnm'></small><button id='jpfnm'></button><li id='jpfnm'><noscript id='jpfnm'><big id='jpfnm'></big><dt id='jpfnm'></dt></noscript></li></tr><ol id='jpfnm'><table id='jpfnm'><blockquote id='jpfnm'><tbody id='jpfnm'></tbody></blockquote></table></ol><u id='jpfnm'></u><kbd id='jpfnm'><kbd id='jpfnm'></kbd></kbd>

        <i id='jpfnm'></i>
        <fieldset id='jpfnm'></fieldset>

      2. <span id='jpfnm'></span>
        <i id='jpfnm'><div id='jpfnm'><ins id='jpfnm'></ins></div></i>

        <ins id='jpfnm'></ins>

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

          • 时间:
          • 浏览:3
          • 来源: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的  ,以是  ,解决要领无效  。