We have a practice of getting user's passwords expired after 60 days and a strong password policy.
When a user tries to enter a password which is not compliant to the policy which is set putty exists without giving any feedback to the user. Below is something i captured from the putty log in one such case.
dumuser
password:
New Password:
sshd-kbdint: Password too short - must be at least 10 characters.
Access denied
No supported authentication methods left to try!
The real problem to me is how to get the putty session not to close and prompt the user of the sin he's comitting, further allow him to change the password accordingly.
All above did not come out on the putty session but the log which i enabled. Normal users do not do such things and complain that they have problems logging in.
I am not sure if I got your problem, but that behaviour is controlled by the configuration of the sshd, not of putty. Tell your configuration to allow more tries, keep the session open or whatever 1001 options are available for the sshd_config.
On our configurations we usually get disconnected too after changing a password when it had to be updated. I guess that some security option in the sshd_config to make sure, the one that just entered it is the same or can remember it or it wasn't just luck entering the password or whatever idea is behind that.
The following is my sshd_config, can you gather anything about the issue i have?.
Oh..the issue again. When a user tries to set a password that is not strong enough as per the policy, putty session exists without any notification to the user. Only way to trap what it wants is through the log of putty which says:
dumuser
password:
New Password:
sshd-kbdint: Password too short - must be at least 8 characters.
Access denied
No supported authentication methods left to try!
Hope this is clear.
Protocol 2
Port 9354
ListenAddress ::
AllowTcpForwarding no
GatewayPorts no
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes
Banner /etc/issue
PrintMotd no
KeepAlive yes
SyslogFacility auth
LogLevel info
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
ServerKeyBits 768
KeyRegenerationInterval 3600
StrictModes yes
LoginGraceTime 600
MaxAuthTries 6
MaxAuthTriesLog 3
PermitEmptyPasswords no
PasswordAuthentication yes
PAMAuthenticationViaKBDInt yes
PermitRootLogin no
Subsystem sftp /usr/lib/ssh/sftp-server
IgnoreRhosts yes
RhostsAuthentication no
RhostsRSAAuthentication no
RSAAuthentication yes
It is clear now yep, but sorry I don't know which option is responsible for that behaviour.
Maybe you read the documentation and play around with the parameters on a test server until you get the one which brings the result you want.
Don't forget to restart the sshd after making changes!
