Thanks to
Martin Mokrejs
Arrigo Triulzi
John Speno
John Ferlan
Kevin Tyle
Richard L Jackson Jr
Joel Gallun
The consensus seems to be that ssh does not interact with the DU
enhanced security option very well. Although it does know how to check
a user's password, it does not do some of the other checks that the
enhanced security option calls for. Upgrading ssh to deal with all of
these checks is on the ssh agenda, but has not yet been implemented.
John Speno suggested configuring ssh with the
--with-login=/usr/bin/login
option. This option is intended to cause sshd to run the standard
login program after it has authenticated the user. The standard login
program would then, supposedly, perform the additional security
related checks (password controls, etc). I tried this, but it did not
appear to have any effect. (I did "make distclean" first and I killed
and restarted sshd after rebuilding the software).
John Ferlan notes:
"First let me state I've never looked at the ssh sources .... given
that..."
"This is probably because the sshd isn't using SIA correctly - if you
have access to the sources make sure it is using the sia_* routines -
specifically it should be calling in order sia_ses_init,
sia_ses_authent, sia_ses_estab, sia_ses_launch, and sia_ses_release.
My "guess" as to why it's bypassing the user locked out scenarios -
probably because the code doesn't call sia_ses_estab. The estab code
is what makes the various calls to the locked out code. If you or
someone has access to the sources, you should call sia_ses_estab -
take care to read what the man page says about environment variables -
many problems have occurred because of that."
"Another thought is that sshd may be using the either the
sia_ses_reauthent() or sia_validate_user() routines. Again in these
cases, the locked out code isn't called."
In any case, the current situation appears to be: you must choose
between either having encrypted sessions on the wire or having
password controls that are properly honored. Hopefully it will be
possible in the future to have both.
My original posting follows:
-----> cut here <-----
Date: Wed, 27 Jan 1999 07:40:04 -0500 (EST)
From: Peter Chapin <pchapin_at_twilight.vtc.vsc.edu>
To: OSF Managers <alpha-osf-managers_at_ornl.gov>
Followup-To: poster
Subject: ssh, password controls, and enhanced security.
Greetings!
The DU machine that I manage was recently broken into by a hacker. In
response, I have rebuilt the system and have tightened security on the new
system to discourage further attacks. For example, I am now running with
the enhanced security package turned on. In addition, I have disabled
telnet access and am currently requiring users to connect to the machine
via ssh (this is an experiment to see if the users will stand for this).
I notice, however, that ssh logins seem to bypass the password controls.
For example, if a user's password has expired they are not forced to
change the password when they log in via ssh. This is true even if they
have used password authentication during their ssh session. This is not an
entirely satisfactory situation and I'm wondering what, if anything, I can
do about it. Is there a program I can put into the login script that will
take care of this matter or do I need to recompile sshd in some way? I'm
using ssh v1.2.26.
It would be ironic if I needed to use unencrypted telnet sessions to gain
access to some of the enhanced security features of my new system!
TIA
-----> cut here <-----
*****************************************************************************
Peter
pchapin_at_twilight.vtc.vsc.edu
http://twilight.vtc.vsc.edu/~pchapin/
Received on Wed Jan 27 1999 - 18:01:29 NZDT