Some time ago I reported this problem with AIX and I think Darren Tucker was kind enough to supply a patch,such that even if the account password had expired,we could still use PublicKeyAuthentication to access the remote machine using that account.I now seem to have a similar problem with Solaris.Is there a patch available for Solaris to allow us to do this. We typically usr root account to remotely manage machines and usually set it to PermitRootLogin without-password as well as disabling remote logins in the o/s. We also use non privileged accounts to sftp stuff around in batch mode and do not want to see password change prompts or connection failures because the password has expired. Thanks.
I think you're referring to bug #383, and if so that was about ignoring the AIX-specific "rlogin" attribute for root in favour of PermitRootLogin, not expiring passwords. Is there any reason you can't turn off password expiration for accounts where you don't want failures due to expired passwords?
Yes,I was in error. Our Security people insist on passwords being expired on any account that is logged into whether locally or not. If we authenticate using PublicKeyAuthentication do we really need to do the account password checking ? Thanks.
Currently sshd checks for password/account expiry very early in the login process (before the authentication methods are negotiated, in auth.c:allowed_user()) so it's probably not a trivial change to omit this check for public-key authentication only. I don't think it's a good idea to do this even if it was easy. (Note that I didn't think the AIX rlogin thing was a good idea at first either :-) AIX currently does this (doesn't expire passwords via SSH password or public-key) and I'm trying to get that *fixed*. It's OK until you need to get in some way other than ssh (eg sshd is broken or you're at the console) then you're screwed. Also note that on Solaris cron jobs will fail for accounts with expired passwords (on Solaris 8 you get "! bad user (testuser)..." on cron's log). If you don't want password expiry, don't enable it for those accounts. If you must have it enabled, set the password to something random (eg "openssl rand 6 | mimencode | autopasswd batchaccount") once per month via cron :-).
What you are saying makes good sense.Thanks for your assistance,I will make these account passwords non expirable and also locked which should keep our security people happy.
I suggest using the no-password string "*NP*" in the password field to disable password authentication as the Solaris system accounts do, rather than locking the account with passwd -l. OpenSSH currently allows public-key logins to locked accounts on some platforms, including Solaris, but this may change in future (see bug #442).
Closing as "INVALID". Unfortunately there doesn't seem to be a "NOTABUG" or "FEATURE" :-).
Mass change of RESOLVED bugs to CLOSED
I think (despite of what Solaris is doing with cron jobs) that a user and an authentication method is different. So when a password has expired, the user should use a different password before successfully logging in via password authentication. But how does that affect public key authentication? Public key authentication should have its own mechanism of validity checking. I see no sense to forbid public key authentication if the password authentication is restricted (password must be changed). Note that having to change the password does not mean the account is disabled or something like that. It just means you should use a different password to authenticate. I think it's perfectly legal to set the encrypted password to an impossible value (thus disabling password logins) while still being able to log in via public key IMHO. To summarize: reopen bug for OpenSSH 3.9 (HP-UX Secure Shell-A.03.91.002).
Like Darren said (2 1/2 years ago): this is a feature, not a bug and won't be changing.
Change all RESOLVED bug to CLOSED with the exception of the ones fixed post-4.4.