I have set up faillog for a SLES 10 SP3 server. I log in through a putty session and i authenticate successfully and the "last failed login" information is displayed and directly beneath that at the prompt this is displayed:
"myusername" password:

If i attempt to type my password again it doesn't work and says, "Sorry, try again."

If i press enter without typing a password it lets me in and i am at the command prompt ready to go.

I have this same faillog set up on my test server and i do not get this second password prompt. The configs on both servers look identical. Permissions on both are the same. I must be missing something? I am very new at this and would really appreciate any help. Thanks.

Are both “ChallengeResponseAuthentication yes” and “PasswordAuthentication yes” set this way in /etc/ssh/sshd_config on the server? I saw a similar behavior with the another ssh client for Windows. You can set the former to no (reload sshd) and test again.

Here is the sshd_config settings for your response:

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

Thanks for the comments but i believe i got this one fixed. I looked in the messages after a login and noticed:

Aug 16 12:40:52 "servername" sudo: "userid" : 1 incorrect password attempt ; TTY=unknown ; PWD=/home/"username" ; USER=root ; COMMAND=/sbin/pam_tally --user "userid" --reset=0


Which lead me to the sudoers file where i added

%users ALL=(ALL) NOPASSWD: /sbin/pam_tally


After that i no longer receive the second login prompt.

I’m not sure whether this is the most safest solution. Where is the sudo command coded? In any ~/.bash_rc or alike?

I have it in /etc/ssh/sshrc in order for it to display for the user logging in to see how many failures they have.


sshrc script:
echo "Last failed login: "; faillog -u `whoami` | grep `whoami`

#faillog -u $USER

sudo /sbin/pam_tally --user $USER --reset=0 > /dev/null
~

This looks like everyone can manipulate the counter of any other user too. faillog is normally also limited to be used by root (at least on my system). There is no default output for failed logins by sshd?

Yes thats true about the counter, although you have to su to root in order to change the counter. I couldn't figure out another way to do it as this is new to me. In the sshd_config there is a line "PrintLastLog yes" but it doesn't do what i need.

Somewhat off topic, because of the sshrc file I cant run nautilus or anything from the terminal anymore.

(nautilus:16718): Gtk-WARNING **: cannot open display:

I believe i fixed this one also. I found a issue similar while searching the webs for the problem. I added this to the sshrc script:

# Set up the local file in which to store the .Xauthority information:
export XAUTHORITY=/tmp/.Xauthority.$USER

# Now create and write the magic cookie information:
if read proto cookie && [ -n "$DISPLAY" ]; then
if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then
# X11UseLocalhost=yes
echo add unix:`echo $DISPLAY |
cut -c11-` $proto $cookie
else
# X11UseLocalhost=no
echo add $DISPLAY $proto $cookie
fi | /usr/X11R6/bin/xauth -q -
fi


Then I added this to /home/"USERID"/.bashrc :

# ~/.bashrc X11 configuration
if [[ -z $DISPLAY ]]; then
# DISPLAY is not set, so check to see what X display is owned
# by the current user and set DISPLAY to this value:
X11_FOLDER=/tmp/.X11-unix
currentUser=`id -u`
bb=`ls -ln $X11_FOLDER | grep $currentUser`
bbb=${bb/*X/:}
usedDISPLAY=$bbb.0
export DISPLAY=$usedDISPLAY
else
# DISPLAY is set, so we assume remote user login via
# ssh and set the XAUTHORITY variable to point to
# proper file.
export XAUTHORITY=/tmp/.Xauthority.$USER
fi

Now I am able to open Nautilus and any other X windows.

Can you suggest a safer solution?

Do you need to reset it at all, as it will also increase the counter even when there was at least one successful login? What about the suggestion in the manpage to use a nightly cron job?

Yes we need to reset the counter because after 3 unsuccessful attempts the user is locked out. I didn't see the cron job suggestion.

From http://linux.die.net/man/8/pam_tally: