[9511] in bugtraq

home help back first fref pref prev next nref lref last post

Re: SSH 1.x and 2.x Daemon

daemon@ATHENA.MIT.EDU (Casper Dik)
Fri Feb 12 14:33:52 1999

Date: 	Thu, 11 Feb 1999 17:33:24 +0100
Reply-To: Casper Dik <casper@HOLLAND.SUN.COM>
From: Casper Dik <casper@HOLLAND.SUN.COM>
X-To:         "Greg A. Woods" <woods@weird.com>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To:  Your message of "Tue, 09 Feb 1999 13:46:09 EST." 
              <m10AIAj-000g6VC@most.weird.com>

>No standard Unix 64-bit password can ever be encoded as anything but 11
>characters plus 2 more for the "salt".  Any field that is less than 13
>characters can never match a valid password and will always result in a
>locked account.  To be ultra careful any field longer than 13 characters
>should be searched for illegal characters, i.e. any non-alpha-numeric or
>not '.' and '/'.  However in practice one can also assume that any field
>longer than 13 characters results in a locked account.

It should be notedm though, that some shadow password implementations
encoded password attributes by adding ",attributes" to the encrypted
string.

Also, in SunOS 4.x "magic" shadow password, the password would look
like "##user".



I don't think it's really all that easy to make ssh work safely without
involving the system's login program or PAM, if it has it.

When exec'ing login, the daemon loses track of the fact whether authentication
was actually successful;  so it can't safely do port/X forwarding in such
cases.

Casper

home help back first fref pref prev next nref lref last post