Solve Linux under Set

Since the use of PHP-SYSLOG-NG monitoring log information, often found that some of the past will ignore the error information, is currently being resolved. One of the errors occurred when I logged on to the server using the key via SSH, and the log information showed:

Nov 10:32:20 PrintServer auth 10:32:20 pam_loginuid[9691]: Set_loginuid Failed opening

Nov 10:32:20 PrintServer auth 10:32:20 Remote (Pam_unix) [9691]: Session opened to user root by (uid=0)

Nov 10:32:20 PrintServer auth 10:32:20 sshd[9689]: accepted publickey for Root from 192.168.228.244 port

1487 SSH2

First, why

Operating system: Red Flag DC Server 5.0

Analysis of the previous system log, and did not find a similar error message, it is suspected that the recent operation caused.

Analysis from two aspects:

1, openssh-server from 4.0P1 upgrade to 4.7P1;

2, use the key to login instead of the original password login method.

First try to use the original password to log in, there is no error, and compared to other machines on the original 4.0P1 version of the state, the use of key landing, there is no error. Since I upgraded openssh-server, I used its own default profile instead of the system 4.0P1 version of the configuration, so I feel that the error, and configuration and use of key landing are related.

　　Second, solve

After searching for the data, you can fix the problem by modifying the Openssh-server configuration file.

Modify/etc/ssh/sshd_config to:

#ChallengeResponseAuthentication Yes

Challengeresponseauthentication No #关闭挑战应答方式

Usepam No #不使用PAM认证

After saving, restart the sshd service.

　Iii. description

A description of the above two parameters, which can be annotated from the Help document:

# Set this to ' yes ' to enable PAM authentication, account processing,

# and session processing. If This is enabled, PAM authentication would

# 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 are just want the PAM account and session checks to run without

# PAM Authentication, then enable this but set passwordauthentication

# and Challengeresponseauthentication to ' no '.

Simply put, if you open the Usepam, you will decide whether to use the challenge response (I don't know whether to translate) according to Challengeresponseauthentication. And this method is based on the password to judge, can not be compatible with key login, so there will be an error.

Different configurations, you can get a completely different result from the log:

1, close challengeresponseauthentication and open usepam

　Login using key:

Reference

Nov 10:57:20 PrintServer auth 10:57:20 sshd (Pam_unix) [10322]: Session opened to user root by root (uid=0)

Nov 10:57:20 PrintServer auth 10:57:20 sshd[10320]: accepted publickey for Root from 192.168.228.244 Port 1595 Ssh2

2, open challengeresponseauthentication and Usepam

Using a key login will be an error, and the use of password login is normal:

Nov 12:23:33 PrintServer sshd (Pam_unix) [24454]: Session opened to user root by root (uid=0)

Iv. Other

At Google, there is another solution: click

is to modify the/ETC/PAM.D/SSHD, the following line of comments:

Session Required Pam_loginuid.so

However, I did not find this line in the system. Instead, you can see from the log that the error was made by Pam calling remote, so I modified/etc/pam.d/remote to comment this line:

Reference

Session Required Pam_loginuid.so

In this way, confirm that the above error will not be reported. But when you log in, the logs will show:

Nov 10:06:31 PrintServer sshd[9582]: Accepted publickey for Root from 192.168.228.244

Port 1228 Ssh2

Nov 10:06:31 PrintServer Remote (Pam_unix) [9584]: Session opened to user root by (uid=0)

Nov 10:06:31 Login--root[9584]: root login on PTS/2 from 192.168.228.244

Send the information from PrintServer to login, log classification will be wrong, not conducive to use slightly.

As for the solution caused by the core not opening the Config_audit function

It is confirmed that the core of the Red Flag DC Server 5.0 is already open Config_audit, so the workaround is invalid.