Mail Archives: cygwin/2000/02/10/18:07:42
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
- Raw text -