Password aging - Problem solved

Allen, Jack Jack.Allen at McKesson.com
Fri Aug 19 15:56:01 UTC 2005


Rick Stevens wrote:
> Allen, Jack wrote:
> 
>> Rick Stevens wrote: AH!  The lightbulb turns on!  I haven't used 
>> telnet in a long time and
>> wasn't aware that's what you were doing.
>>
>> First, may I suggest that you disable telnetd immediately.  Never use it
>> unless you are behind a really strong firewall and can guarantee the
>> security of your network.  The telnet protocol is completely insecure
>> and sends EVERYTHING (including passwords) through in cleartext--which
>> is a bloody horrible idea as you can well imagine!
>>
>> Now, on top of the security issues I mentioned above, all telnetd cares
>> about is whether login validates you or not.  Since the account hasn't
>> been disabled, login will approve you and telnet lets you log in.  Note,
>> however, that the warnings that login gives are (rather unceremoniously)
>> thrown away by telnetd.
>>
>> If, however, password aging had expired the account (and therefore login
>> would reject you), then telnetd wouldn't let you in either.  telnetd is
>> a "pass or fail" system, not a "pass, pass with warnings, or fail"
>> system.
>>
>> Hope that explains it a bit, and sorry about the misunderstanding.
>>
>> ===========
>>     I know all about the lack of security with telnet. Our development
>> systems are all behind a very restricted firewall and our product is
>> deployed at our customers behind firewalls. The product requires telnet
>> because of some old terminal emulation with enhancements that has to 
>> be used
>> by the users.
>>
>>     I don't know exactly how Linux functions as far as telnet and login,
>> but I do know how telnet and login work UNIX systems. The login prompt is
>> presented to the user by the login program which communicates through the
>> telnetd process back through the network. The telnetd process is actually
>> the parent process for login. The login program does all the prompting 
>> the
>> user for the login name and their password and does all the validation,
>> password aging checks and so forth. Then it overlays itself with the 
>> shell
>> specified in the passwd file. As I said earlier, when I connect via 
>> telnet
>> it runs login, when I connect via ssh it also runs login. I checked this
>> when I connected before I even entered a login name. Therefore it 
>> seems to
>> me that login is being used by both ways of connecting to the system 
>> and it
>> should be the one doing validation and aging checking. If this is true, I
>> still can not figure out why one does aging and the other does not.
> 
> 
> It's not aging, it's the _warnings_ that login gives about the state of
> the password that aren't propagated through the telnet pipe.  I'm not
> 100% sure of this, but if telnetd wasn't built with AUTHENTICATION
> enabled, these messages are ignored, and I don't know how it was built.
> 
>>     Just as a side question, when is the PAM configuration files in
>> /etc/pam.d used? There is one for password, login, and sshd. I checked 
>> the
>> last accessed time on all of them and password and login are never 
>> accessed.
>> So what are they there for?
> 
> 
> Those control what PAM things are required for the named application.
> In other words, /etc/pam.d/passwd controls access regarding the use of
> the /usr/bin/passwd _program_, not access to the /etc/passwd _file_.
> File access is handled by the standard permissions and ACLs.
> 
> Similarly, /etc/pam.d/login controls use of the /bin/login program, and
> then only if it's invoked by a user--not by another program (e.g. sshd
> or telnetd).  It's assumed that, because another program is invoking it,
> that program has already authenticated in some manner--at least the
> session must be valid.  If you look at the differences between the
> /etc/pam.d/sshd and /etc/pam.d/login files, you'll see that sshd's
> requirements for the session portion are less restrictive so it can run
> login.
> 
>>     Does anyone have the source loaded and can look at login and see if
>> it uses the PAM files or calls other things that may use them or deals 
>> with
>> the shadow file and aging directly?
> 
> 
> login does all that.  Again, aging is taking place.  You simply don't
> see the warnings that login issues when you use telnet, that's all.

Followup:

telnetd isn't even PAM-aware, so it's entirely possible that it never
checks aging (it doesn't invoke pam_stack.so).  login will still fail
if the account is expired, but you won't get any messages.

=============
	I assumed telnetd was not PAM-aware, but login should be. You have
been a big help replying to this and other questions I have asked, but I
have to disagree with you about telnetd not passing the warning messages. It
basically passes what ever it reads on the master side of a pseudo tty that
another program such as login or the shell or vi writes to the slave side
and sends it across the network. Therefore when a connection via telnet is
done and login is run to prompt the user for their login name and password
it can send the warning message and prompt to enter a new password. There is
nothing special about this that would keep telnetd from passing the
characters along.

	Doing strings on /bin/login shows libpam.so.0 and libpam_misc.so.0
and several pam_* names, I assume are PAM library calls. So it would seem
login is PAM-aware. I still think there is a configuration file somewhere
that has to be changed to make login really use PAM. Then it would work just
like su and ssh about identifying the password has aged.

	I found /etc/login.def, but not much other than what is already in
the file commented out, as far as what all can be put there to control
something. Most of the parameters seem to deal with adduser, default shell
and some other things.

Thanks:
Jack Allen

===========
	Follow up: First I have to correct something I said earlier. When
you connect via ssh, it does NOT run the login program at the start like
telnetd does.

	I have resolved the problem. I had enabled /etc/xinetd.d/kbr5-telnet
for telnet service. It calls /usr/kerberos/sbin/telnetd, which is suppose to
handle Kerberos 5 authentication and standard telnet connections. So it
looks like when a standard telnet connection is made, it sets something or
passes or does not pass an option to login which causes it not to do the
password aging checking. There is also /etc/xinetd.d/telnet which calls
/usr/sbin/in.telnetd, which I believe is the old standard telnet that sets
something or passes and option to login. I will have to do some more testing
to see if I can determine what argument is or is not passed to the login
program when called from the differ telnetd programs.

Thanks:
Jack Allen




More information about the Redhat-install-list mailing list