Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
Message-ID: <38A34613.20788DC8@ece.gatech.edu>
Date: Thu, 10 Feb 2000 18:13:23 -0500
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Christian Engwer <christi AT fsphys DOT zbt DOT uni-heidelberg DOT de>,
        cygwin AT sourceware DOT cygnus DOT com
Subject: Re: ssh and authorized_keys
References: <20000210231136 DOT A9794 AT mathphys DOT fsk DOT uni-heidelberg DOT de> <38A3433E DOT 572B98D5 AT ece DOT gatech DOT edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Charles Wilson wrote:
> 
> One way of solving a lot of these problems is to
> "initialize" the ssh daemon. In other words, login once
> using password authentication. Then, the sshd stores the
> password in memory (encrypted using the server key; the
> server key is regenerated every hour [usually] so the
> in-memory database needs to be re-encrypted each time the
> server key changes). After than, RSA authentication could 
> work, since once the user is RSA-authenticated, the daemon
> looks up the password in the encrypted in-memory database,
> unencrypts it using the server key, and performs the
> authentication/credential update in the NT security system.
> 
> You'd have to reinitialize the SSH daemon each time the
> service restarted or the machine rebooted.
> 

I thought of another difficulty. When running SSH2 in compatibility
mode, under normal circumstances it spawns a new SSH1 daemon each time a
user attempts to connect using SSH1. Thus, the SSH1 daemons are
transient an can't be initialized. So, for the SSH2-SSH1 compatibility
mode, you'd have to define a new API so that the spawned SSH1 could 

(A1) check it's own in-memory database (if it's running standalone)

(A2) ask the parent SSH2 daemon if IT has the password for user 'john'
-- if so, then ask the parent SSH2 daemon for the plaintext password.

(A3) if neither of these are true, then do a password authentication
   (B1) if running standalone, then encrypt the password using the SSH1
daemon's server key and store it in the SSH1 daemon's encrypted,
in-memory database.
   (B2) if running as a child, pass the plaintext password back to the
parent so that IT can encrypt it with the SSH2 server key and store it
in the SSH2 daemon's encrypted in-memory database.


There are LOTS of opportunities here for trojans/interceptors. OTOH, it
IS NT, after all, which isn't very secure to begin with, so...

--Chuck

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com