Balazs Scheidler <[EMAIL PROTECTED]> writes:
> I've more or less completed publickey support in lshd and lsh. To use this
> apply the following patch, or alternatively download my patched version
> from:
>
> http://www.balabit.hu/downloads/lsh/lsh-0.1.15-bazsi.tar.gz
Cool!
> To use publickey authentication you need:
> 1) create a keypair using lsh_keygen | lsh_writekey
> 2) create a directory ~/.lsh/authorized_keys_md5
> 3) find out the md5 sum of your public key:
> cat ~/.lsh/identity.pub | sexp_conv -i transport -o canonical | md5sum
> 4) touch a file named the md5sum of your public key into existence under
> ~/.lsh/authorized_keys_md5
You can combine the last two steps as
touch `sexp_conv <identity.pub -i transport -o canonical |md5sum `
I just merged and checked in the previous version of your patch.
diff -urN --exclude-from=diff-exclude lsh-0.1.14/src/client_keyexchange.c
lsh-0.1.14-bazsi/src/client_keyexchange.c
--- lsh-0.1.14/src/client_keyexchange.c Sun Oct 24 21:59:48 1999
+++ lsh-0.1.14-bazsi/src/client_keyexchange.c Wed Nov 3 13:37:40 1999
@@ -175,8 +177,13 @@
{
CAST_SUBTYPE(lookup_verifier, v,
ALIST_GET(closure->verifiers, hostkey_algorithm_atom));
- assert(v);
+ /* FIXME: clean exit in this case */
Not quite needed. The Right Way to do this is to make sure that we
never advertise support for a hostkey algorithm for which we don't
have a verifier.
diff -urN --exclude-from=diff-exclude lsh-0.1.14/src/client_userauth.c
lsh-0.1.14-bazsi/src/client_userauth.c
--- lsh-0.1.14/src/client_userauth.c Mon Aug 30 20:10:34 1999
+++ lsh-0.1.14-bazsi/src/client_userauth.c Mon Nov 1 19:35:31 1999
For more thoughts about the organization about this, see the new NOTES
entry at the end of this message.
diff -urN --exclude-from=diff-exclude lsh-0.1.14/src/spki.c
lsh-0.1.14-bazsi/src/spki.c
--- lsh-0.1.14/src/spki.c Wed Sep 22 21:00:45 1999
+++ lsh-0.1.14-bazsi/src/spki.c Mon Nov 1 19:37:37 1999
@@ -231,6 +240,189 @@
struct command spki_public2private
= STATIC_COMMAND(do_spki_private2public);
+
+/* parses an already parsed S-expression, and inserts it into an alist */
+/* GABA:
+ (class
+ (name spki_parse_key)
+ (super command)
+ (vars
+ (random object randomness)))
+*/
+
+static struct keypair *
+parse_dsa_private_key(struct randomness *random,
+ struct sexp_iterator *i,
+ struct exception_handler *e)
+{
+ mpz_t p, q, g, y, x;
I'm afraid this function was broken; it doesn�t seem to deallocate the
bignums properly. A think I fixed this, and for simplicity I also
moved the exception stuff to the calling function.
You can look at http://www.lysator.liu.se/~nisse/lsh/src/spki.c, as
usual.
I'd also like to turn the key reading functions into commands that
doesn't use blocking read. I'ts not terribly important for the client,
but on the server side, and if the client sends only the spki key hash
rather than the public key, then the server has to read the public key
from somewhere.
BTW, when the server reads files in a user's home directory, what are
the caveats? The user may have links to files he or her is not
authorized to access. Or links to special files like /dev/zero, which
could keep the server quite buzy. Are there more cases than that that
must be addressed? I would prefer to be reasonably liberal and not try
to rule out symlinks completely, but instead check permissions and
have some limits on the file size.
At last, the NOTES entry:
CLIENT SIDE OF USER AUTHENTICATION
About publickey authentication, one way to organize this as follows:
First, lsh.c parses its options and collects all -i keyfile options
into a list. By default, the list contains ~/.lsh/identity. There
should also be some way to specify an empty list, i.e. to disable
public key authentication.
Later on, we iterate through this list, and collect any private keys
we find into a list of keypairs. A file can contain zero or more keys,
and i/o and parse errors are not fatal errors. dss keys may split into
two keypair structures; one for "ssh-dss" and another for "spki" (this
splitting could be moved to later on, but I think that will require
some more information than the keypair struct to be kept around). The
list is passed on to the userauth mechanism, perhaps using something
like
(publickey-login (map-append read-private-key-file file-list)
(userauth_service (handshake (connect port))))
When we have an agent, we will also ask the agent for additional keys
(a keypair from an agent will contain a public key and a "proxy
signer" object, which will create signatures by communicating with the
agent).
When getting into the userauth proper, we try all available keys, by
sending USERAUTH_REQUEST messages for all of the public key, and
whatching for USERAUTH_PK_OK replies. When we get one, we create a new
signature and send a new USERAUTH request. If all keys fail, we fall
back to password authentication.
At first, we'll support only one keyfile at a time, but we can still
have several keys.
Also the lshd server currently can't deal with multiple userauth
requests in parallell.
On a higher level, we may have several userauth methods that we want
to try, say first public key, then agent public keys, and last
password authentication.
I think the best way to keep track of this is to let the userauth
mechanism get a list of methods. It tries the first method; when it
failes, we should continue with the next useful method. To do this, we
advance one element on the methods list, and we also look at the list
of useful methods according to the latest USERAUTH_FAILURE message
from the server. Then we try the next useful method.
Perhaps each userauth method could be represented as a command? I
think it is better to handle the SETUP and CLEANUP done internally by
the method. Each userauth method should probably request the same
username and service.
Does this make sense?
Many thanks for your work!
/Niels
