OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Bugtraq archives for 1st quarter (Jan-Mar) 1999: Re: SSH 1.x and 2.x Daemon

Re: SSH 1.x and 2.x Daemon

Jan B. Koum (jkbBEST.COM)
Sun, 24 Jan 1999 14:39:30 -0800 

        This is not the case with ssh 1.1.26 running on FreeBSD 2.2.8
        If I expire an account:
        Expire [month day year]: January 1, 1999
        Then when I try to ssh in I just get:
        Permission denied.

-- Yan

On Sat, Jan 23, 1999 at 05:06:44PM -0500, KuRuPTioN <kuruptionCHA0S.COM> wrote:
> 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).
>
> [rootepicenter /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
> [rootepicenter /etc]# date
> Sat Jan 23 13:57:51 PST 1999
> [rootepicenter /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.
> [rootepicenter /etc]# ssh1 -l lamer localhost
> lamer127.0.0.1's password:
> No mail.
> (lamerepicenter) 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