ssh and using Authorized Keys File ??

[MikeL_4]

We have several what we call Admin ID's that the applications group uses to administer there applications from...

They are allowed direct login to these ID's, and are forced to us sudo which issues the su for them to log into these accounts...

The ID's do have ssh-keys generated for these Admin ID's so that they can communicate between other servers with these same ID's set up on them...

We are required by our security group to have expiring passwords set on these ID's, even though there is no direct login to the ID's which brings up the issue we are having..

Should the ID's password expire, the scripts that communicate with this ID between servers that is using the ssh-keys set up in the authorizedkeys file, also stops working..
As soon as the password is set to some new password it starts working again...

Is there something that can be done, when the password expires, that will allow ID's with the ssh-keys defined to continue to function ??

[Steven Schweda]

So, if I understand your description, the
actual problem here is that you can't use
SSH to log in as a user whose password has
expired. (So, not really much to do with the
"authorized_keys" file, which isn't
changing.) If that's correct, ...

> They are allowed direct login to these
> ID's, [...]

> [...] even though there is no direct login
> to the ID's [...]

I'm confused.

> We are required by our security group [...]

Apparently, you need to pursue this problem
with them. I know nothing, but I suspect
that any scheme which allows a user with an
expired password to log in would be a _real_
security problem. (Which is different from
an intentional service disruption caused by
a lame policy decision made by "our security
group".)

If no one actually uses a password to log in
as one of these Admin users -- passwordless
SSH connections only -- then I would think
that "our security group" could set
complex/random passwords for them, passwords
which are known to no one. Then, who could
care if they ever expire? And if long-life
passwords are still considered a problem,
even if no one actually uses (or even knows)
them, then let "our security group" change
them whenever it wants to, so long as it
doesn't ever let them expire.

If "our security group" is not entirely
populated by morons, then it should be
possible to agree on a policy which satisfies
any rational security requirements while
allowing necessary work to get done. In some
cases of nonsensical policies, there may be
no technical solution. The real mystery here
is what "our security group" is expecting to
achieve by having these passwords expire.
Especially if no one is actually using them.

Alternatively, one might be able to extract
the password expiration date from the
authorization data base, and run a "cron"
job which automatically sends increasingly
nasty e-mail messages to "our security group"
as password expiration dates grow nigh.
Sometimes a non-technical ("social
engineering") solution can substitute for a
technical solution. (Or, ideally, educate
"our security group" regarding the benefits
of a more enlightened policy.)

[MikeL_4]

.