Solve Linux under Set

Source: Internet
Author: User
Tags auth system log ssh

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 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:


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 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

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:


Session Required

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

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

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.

Related Article

E-Commerce Solutions

Leverage the same tools powering the Alibaba Ecosystem

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: and provide relevant evidence. A staff member will contact you within 5 working days.