diff --git a/ChangeLog b/ChangeLog index d4fc6aaf2b5531d3080027b431893583cb2e6078..315af88e8e91b1cb028484a1c3ccc341ba547b2c 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,8 @@ Sun Dec 20 20:11:02 1998 + * arcfour.c, blowfish.c, cascade.c, cbc.c, des.c, hmac.c, md5.c, + sha.c: New files, extracted from crypto.c and abstract_crypto.c. + * server.c (do_line): Accept client version 1.99, if DATAFELLOWS_SSH2_GREETING_WORKAROUND is defined. diff --git a/doc/NOTES b/doc/NOTES new file mode 100644 index 0000000000000000000000000000000000000000..6e50235f07bdbb1129aa8015eaee9ec4ad2be48f --- /dev/null +++ b/doc/NOTES @@ -0,0 +1,91 @@ +This file contains notes that don't fit in the TODO or TASKLIST files. + + +NO PAM SUPPORT + +I spent a day reading the PAM documentation. My conclusion was that +PAM is not at all suited for handling ssh user authentication. There +are three main problems, the first two of which would be show-stoppers +for any SSH server, while the last is a problem that affects servers +like lshd which doesn't fork() for each connection. + +(i) The design of PAM is to hide all details about the actual +authentication methods used, and that the application should never +know anything about that. However, ssh user authentication is about +particular authentication methods. When the client asks which +authentication methods can be used, the server should be able to tell +it, for example, whether or not password authentication is acceptable. +When the client tries the password authentication method, no other +method should be invoked. But PAM won't let the server know or control +such details. This problem excludes using PAM for anything but simple +password authentication. + +(ii) PAM wants to talk directly to the user, to ask for passwords, +request password changes, etc. These messages are not abstracted *at* +*all*, PAM gives the application a string and some display hints, and +expects a string back as the users response. This mode of operation +doesn't fit with the ssh user-authentication protocol. + +If PAM would tell the ssh server that it wanted the user to chose a +new password, for instance, the server could the appropriate message, +SSH_SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, to the client, and pass any +response back to PAM. But PAM refuses to tell the application what it +really wants the user to do, and therefore there's no way the server +can map PAM's messages to the appropriate SSH packets. This problem +excludes using PAM for password authentication. + +(iii) The PAM conversation function expects the server to ask the user +some question, block until a response is recieved, and then return the +result to PAM. That is very unfriendly to a server using a select() +loop to manage many simultaneous tasks. This problem by itself does +not exclude using PAM for a traditional accept(); fork()-style server, +but it is completely unacceptable for lshd. + + +DSS KEY GENERATION + +I have implemented DSS key generation, using the method recommended by +NIST (algorithm 4.56 of Handbook of Applied Cryptography) to generate +the public primes. According to Werner Koch, the method used in GNU +Privacy Guard, suggested by Lim-Lee at Crypto '97, may be a lot +faster: + +> I generate a a pool of small primes (160 bits for a prime up to 1024 +> bits), multiply a couple of them, then double the result, add 1 and +> check wether this is a prime (5 times Rabin-Miller) and continue +> with a new permutation until I found a prime. (p = 2*q*p1*p2 ... * +> pn + 1). + + +CLOSING CHANNELS + +The right conditions for closing a channel, and in particular a +session, are somewhat subtle. There are three events that may happen +in arbitrary order: + +(i) The client sends EOF on the channel. + +(ii) The server sends EOF on the channel (this happens when there are +no more processe which has the files the server has opened for stdout +or stderr open). + +(iii) The child process created by the server dies. An exit-status or +exit-signal message is sent to the client. + +lshd handles these condtions as follows: It will not send a CLOSE +message until *all* the three events above have occured. Naturally, +this could cause the channel to stay open for ever, for instance if +the child process has started a background job that happens to keep +its stdin open (perhaps without ever using it). In most cases this is +not what you want. + +The lsh client will, by default, respond to exit-signal or exit-status +with an EOF message. If this is the last event keeping the server from +closing the channel, the channel is finally closed, on the server's +initiative. + +It is conceivable that the user may want to continue communicating +with remaining child processes even after that the first process has +died (i.e. after that it has received exit-status or exit-signal from +the server). In this case, the client should be considered not to send +EOF until it detects EOF on stdin. diff --git a/doc/TASKLIST b/doc/TASKLIST index 251d50e8687e6132f6cf8f974daade511422ec5e..63f41ef386207d25dc4908619734b2ff473d15c7 100644 --- a/doc/TASKLIST +++ b/doc/TASKLIST @@ -1 +1,40 @@ -PAM support. (No. Looked at it. Didn't like it). +This file describes some mostly independent subprojects for lsh. +Before starting on any of them, please contact me (Niels Möller +