[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ale] SSH 1.x and 2.x Daemon (fwd)



This might be something of interest

----
"You know the one thing that's wrong with this country? Everyone gets
   a chance to have their fair say." - Bill Clinton, May 29, 1993

---------- Forwarded message ----------
Date: Sat, 23 Jan 1999 17:06:44 -0500
 From: KuRuPTioN <kuruption at CHA0S.COM>
To: BUGTRAQ at NETSPACE.ORG
Subject: SSH 1.x and 2.x Daemon

There seems to be incomplete code in the SSH daemon in both versions 1.2.27
and 2.0.11 (only tested).  The bug simply allows users who with expired
accounts (in /etc/shadow) to continue to login even though other such
services such as ftp and telnet deny access.  Here is the log using 1.2.27
(but the same happens with 2.0.11).

[root at epicenter /etc]# chage -l lamer
Minimum:        3
Maximum:        30
Warning:        5
Inactive:       -1
Last Change:            Jan 01, 1999
Password Expires:       Jan 31, 1999
Password Inactive:      Never
Account Expires:        Jan 22, 1999
[root at epicenter /etc]# date
Sat Jan 23 13:57:51 PST 1999
[root at epicenter /etc]# telnet localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
login: lamer
Password:
Your account has expired.  Please contact the system administrator.
Connection closed by foreign host.
[root at epicenter /etc]# ssh1 -l lamer localhost
lamer at 127.0.0.1's password:
No mail.
(lamer at epicenter) lamer>

........

Now I wanted to try whether the account expiration worked using SSH, and it
does.  If a user's password has expired, then SSH will prompt following the
login for the user to enter a new password and disconnect them if they fail
to (like a telnet would).

I have reported this problem to the SSH bug e-mail address about 2 weeks ago
with no response.

Current System Configuration:
Linux 2.0.36
Shadow Utilities 980724
SSH 1.2.27 and 2.0.11 (both daemons)

Any solutions (patch?) to this problem would be appreciated.  Currently I
just run a shell script to change the user's shell to deny them, but this
shouldn't be necessary since this is one of the listed features of the
Shadow Utilities.

Thanks.
Raymond T Sundland