ssh login only accepting 8 character passwords.

[Paul meaden]

Hi,

Has anyone come across this before. I recently upgraded to HPUX Secure Shell 3.91. Since the upgrade, I cannot use a password of greater that 8 characters, when attempting an ssh login using Unix password authentications (i.e. not key-pair authentication). Please see following for example:

As root:

# useradd -m testac
# passwd testac
enter password greater that 8 characters ..

As user fred:

$ su - testac
enter password and login is successful
$ exit

$ ssh testac@localhost
enter same password which worked above, and get permission denied.

If the whole exercise above is repeated, but a password of 8 characters in length is created, the "ssh testac@localhost" works fine.

This is a trusted system. I have been all through the trusted parameters, and there is nothing amiss. The u_maxlen is set to 20. Also, interestingly, the failed ssh logins do not register in /tcb/files/auth/t/testac as failed logins.

Any help much appreciated...

[Peter Godron]

Hi Paul,
have you tried run the ssh with debug mode?
Also what is the error message you got?
Have a look at thread:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?admit=716493758+1108115209430+28353475&threadId=679278
Regards

[Gordon Morrison]

Maximum password length is 8 characters. Any extra characters after the first 8 are ignored by the OS, but perhaps ssh is cleverer than that and checks the extra characters. If so, this may cause a conflict with the OS.
Can I suggest using max 8 char passwords?

[Florian Heigl (new acc)]

You're running into a limitation with the standard passwort algorithms.

Have a try - use
verylongpassword as a passwort and try logging in while typing verlongpassworD - I'm afraid it'll work.
IIRC this is a NIS compatibility limitation, which nowadays would be unneccesary as NIS+ supports longer passwords. But noone uses NIS+ for it's only 10 years old, so the limit is still there. ;)

I am not sure, but I feel this could go away when enabling shadow passwords or Trusted System mode, but I never cross-checked it.

Maybe check the pwconv man page on this.

[John Payne_2]

We had the same problem. The solution from the support folks was to add the following line to /opt/ssh/etc/sshd_config:

UsePAM yes

After making the change and restartring sshd, things worked fine.

Hope it helps.
John

[Jeff Schussele]

Hi Paul,

This is an OS-level issue - not SSH.
IF the > 8 PWs were in use before conversion to Trusted - *only* the first 8 chars were converted & encrypted.
They can continue to use the old PW = BUT *only* the first 8 chars because the system evals *all* the chars & adding the extra chars will cause a decrypt failure.
Of course, the real solution is to change the PWs to <= 8 chars.

My $0.02,
Jeff

[Steven E. Protter]

In spite of the ability to have longer passwords and logins, I find that characters beyond the eigth are ignored.

My system is trusted and we allow up to 40 character passwords.

We get around this annoying issue by enforcing password complexity with an /etc/default/security file.

I am attaching mine as an example.

SEP

[Paul meaden]

Many thanks to John Payne. The UsePAM parameter nailed it. Thanks to everyone else who contributed.

Paul.