Commit 2681fa53 authored by Niels Möller's avatar Niels Möller

*** empty log message ***

Rev: ChangeLog:1.12
Rev: doc/NOTES:1.1
Rev: doc/TASKLIST:1.3
Rev: doc/TODO:1.22
parent b6dd9218
Sun Dec 20 20:11:02 1998 <nisse@puck>
* 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.
......
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.
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
<nisse@lysator.liu.se); someone may already be working on it already,
and we need to coordinate.
Port forwarding services
TCP,
X,
ssh-agent,
UDP (not in the spec, but that's no reason why it couldn't be
implemented).
PTY support.
Compression (zlib) support.
User interface. This includes command line options, configuration
files, an escape-character mechanism and any features attached to that,
including a command mode to create or terminate forwarded ports and
channels interactively.
More user authentication methods; in particular the public-key method.
Key storage, generation and management.
SPKI support. Using SPKI certificates to grant access for groups and
individuals seems seems like a good thing to me (even if I suspect
that its usefulness is greater for more specialized services than
login). I also find it appealing to send SPKI hashed key id:s rather
than the public keys themselves in the publickey authentication
protocol.
SSH agent (does anybody have a specification of the protocol(s) used
by ssh-agent?)
Projects not to do:
PAM support. (Looked at it. Didn't like it. See NOTES for details).
......@@ -99,19 +99,6 @@ this case, the local process should close it's stdout and stderr, but
not close the channel until it has received a close message and
possibly an exit status.
The server's close message should somehow be delayed until the dead
process has been reaped. I think the Right way is for the server to
initiate CHANNEL_CLOSE when all of the following conditions are true:
× The process is dead (and its exit status has been send to the
client).
x EOF has been detected on both stdout and stderr.
× An EOF message has been received from the client.
The client may want to respond to the exit-status message with an
CHANNEL_EOF message, unless it wants to talk to any forked children
that may still keep the stdin open.
USER INFO
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment