This is the mail archive of the
mailing list for the Cygwin project.
Re: OpenSSH 2.1 to Windows2000
- To: "Charles S. Wilson" <cwilson at ece dot gatech dot edu>
- Subject: Re: OpenSSH 2.1 to Windows2000
- From: Corinna Vinschen <corinna at vinschen dot de>
- Date: Mon, 19 Jun 2000 20:09:09 +0200
- CC: Ian Blenke <icblenke at 2c2 dot com>, "'cygwin'" <cygwin at sourceware dot cygnus dot com>
- References: <ED90508D11B4D3119D4700204840658601262560@CICERO2> <394E5871.9A06B8E3@ece.gatech.edu>
- Reply-To: cygwin <cygwin at sourceware dot cygnus dot com>
Perfect description, Chuck!
"Charles S. Wilson" wrote:
> > ???
> > > > However, trying to run ssh in "multiuser mode" spawned via
> > > > inetd (added sshd -i to /etc/inetd.conf) results in refused
> > > > authentication (most likely due to mucked up home directories).
> > >
> > > did you read the README?
> > Yes, I've read the README. It just doesn't make sense.
> > Why should RSA authentication work in a single-user
> > configuration, but not in a multi-user one?
> > If I turn on PasswordAuthentication, ssh does work
> > correctly. That's not good for automation that
> > works far better with null-phrased RSA keys.
> AFAIK, you must use a password (the real, true, NT-authentication
> plaintext password) to change the ownership of a process -- such as the
> spawned sshd that handles a user session.
> So, the master sshd can run under any user you like, and allow any user
> to login -- as long as you give it the NT password so that it can spawn
> the sub-sshd as the remote user. So password authentication works "just
> like unix".
> However, with RSA, you don't give the NT password, so the master sshd
> cannot create a new process as the remote user -- the spawned sshd runs
> as the same user as the master sshd.
> There's only one way around this, AFAIK: store an encrypted database
> with the NT passwords. Once RSA authentication is complete, look up the
> user's encrypted NT password (and unencrypt to *plaintext*) and use that
> to spawn the sub-sshd as the remote user. This is (a) fundamentally
> insecure and (b) requires manual maintainance -- there is no way to
> extract the plaintext password from the NT SAM, so the user will have to
> encrypt/store the plaintext password manually -- and remember to update
> the sshd password database when changing the NT SAM.
> Want to unsubscribe from this list?
> Send a message to firstname.lastname@example.org
Cygnus Solutions, a Red Hat company
Want to unsubscribe from this list?
Send a message to email@example.com