<acronym id='nle0r'><em id='nle0r'></em><td id='nle0r'><div id='nle0r'></div></td></acronym><address id='nle0r'><big id='nle0r'><big id='nle0r'></big><legend id='nle0r'></legend></big></address>
    <i id='nle0r'></i>

      <code id='nle0r'><strong id='nle0r'></strong></code>

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

    3. <i id='nle0r'><div id='nle0r'><ins id='nle0r'></ins></div></i>
      1. <dl id='nle0r'></dl>
        <ins id='nle0r'></ins>

          <fieldset id='nle0r'></fieldset>

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

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