Exalogic Elastic Cloud X3-2 Hardware
 
Oracle Exadata Storage Server Software
 

PLA-Support>Eng Systems>Exadata/ODA/SSC>Oracle Exadata>DB: Exadata_EST
 

SSH connections to a Linux server fail, and a long wait time must occur before retries.
Also- unable to unlock user account.

Applies to:

Symptoms

Unable to SSH to Linux server. Account is locked out as a result of too many retries.
Connection retries must wait 10 minutes / 600 seconds between retries can occur.

Unable to unlock user account

Changes

Linux PAM settings tightened

Cause

The configuration for the PAM authentication service has been modified to provide a more secure configuration by default.

The more secure configuration makes it more difficult for malicious users to access the system.
The default “wait” time between an unsuccessful login and the next “attempt” is set to 600 seconds (10 minutes)

The mechanism to "unlock" a user account may not work using the pam_tally2 command.

Solution

In modern Linux distributions, the default security mechanism governing SSH connections is the PAM service.

This service mainly uses one configuration file to drive the wait time and lockout value when too many incorrect connections are attempted:
/etc/pam.d/sshd


Basically one line is used to define these timeouts/lockouts:

auth required pam_tally2.so deny=5 onerr=fail lock_time=600


The values to note are:

auth required pam_tally2.so deny=5 onerr=fail lock_time=600 

The value set in the "deny" parameter governs how many attempts can be made to login using a user account before that account is locked. In this case it is set to 5 retries.
The value set in "lock_time" is the parameter which governs how long one must wait before attempting to log in again. This value appears to be set much higher than in the past- which is a result of "hardening" the SSH login process, and to discourage attempts to "guess" the password.


Both values can be altered. Setting them as follows causes the behavior noted:

auth required pam_tally2.so deny=3 onerr=fail lock_time=10 


In this case- you would only have 3 attempts to login using an account before that account is locked.
Also- the time you will be forced to wait before attempting another login is now reduced from 10 minutes (600 seconds) to 10 seconds.

Changes made to /etc/pam.d/sshd should also be made to /etc/pam.d/login to ensure that the desired settings are consistent for all logins.

After making changes to this file, the changes will only become effective when the following command is issued by the "root" user:

# service sshd restart

The PAM service writes to several files in logging connections, and attempts made which were not successful:

/var/log/faillog The file /var/log/faillog records the failed attempts to log in.
/var/log/secure The file /var/log/secure records all SSH connections into the server.
/var/log/tallylog The file /var/log/tallylog acts as the "counter" which PAM uses to determine whether to lock a user account

Only the file /var/log/secure is "human readable", so manually editing either faillog or tallylog is not an option.
During testing though you can watch the secure file and monitor the login attempts, tally counters and more.

The main command at your disposal for finding out whether invalid logins were attempted, and whether a user account is locked is:

# pam_tally2                                                                                                            


This command displays all user accounts with a non-zero invalid login attempt count


If the account is listed with a number under the "Failures" column- then you know that this account has seen one invalid login attempt.
If a user account has so many invalid attempts that the value in "deny" is met or exceeded- then that user account is locked. 

# pam_tally2
                                                               
Login    Failures   Latest failure       From                  
oracle   7          05/15/12 10:05:10    server.domain.com     




In order to unlock this user account- the following command must be used:

# pam_tally2 --file /var/log/tallylog --user <user> --reset

Where <user>is the user account which is locked.


It is possible to unlock the account without using the "--file /var/log/tallylog":

# pam_tally2 --user <user> --reset                                                                                 

But it has been found on occasion that the “pam_tally2 … -reset” does not always work unless you define the tallylog (--file /var/log/tallylog).


Now when the command "pam_tally2" is run, the user which was locked out should not be listed as it's "tally" has been reset to 0.

# pam_tally2

Another older method of locking user accounts at the UNIX/Linux level is to use the command "password" with the parameters "-l" or "-u"
This is a method which has been in use for a long time, but is only usable when manually locking a user account by the root user (Administrator).

The command is used as follows:

passwd -l <user> #Locks the <user> account
passwd -u <user> #Unlocks the <user> account

References

This solution has no attachment