On 7 Jan 2000, Niels M�ller wrote:
> Copying kwys from captured_keys to known_hosts should work.
It didn't, I'll look into that more this lunch, and maybe this weekend.
> > server_publickey.c:100: do_authenticate: Raising exception Unsupported
> > public key algorithm. (type 16385), using handler installed by
> > server_userauth.c:453: do_userauth
>
> Hmm. There seems to be two problems here: First of all, neither lsh
> nor lshd should die if public key user auth failes. You don't say if
> the server survived or not? Secondly, the unknown algorithm message
> seems strange; both sides should support the same two algorithms: spki
> and ssh-dss. But the latter problem should not be fatal.
What compilers has lsh been tested on? What I've been seeing is that any
error returned to the client causes the client to core dump (in this case
it did, but the server continued to function), so that's where I'm going
to focus my attention. It's almost as if lsh is using some part of C++
that isn't implemented correctly, like exceptions. I know this isn't
the case, since there isn't any C++ code there, I just want to rule it
out. FWIW, FreeBSD 3.X is using gcc 2.7.2.
Note: with the authorization done correctly, it lets me in. If
~/.lsh/identity(.pub ?) doesn't exist or --no-publickey is specified, it
correctly asks me for a password and lets me in. The only failure mode if
publickey authorization is attempted but fails.
> Current versions uses sha1 rather than md5. The right command is
> something like
>
> touch ~/.lsh/authorized_keys_sha1/`sexp_conv < some_pubkey --hash sha1 --raw-hash
>--once`
>
> Or use the script src/lsh-authorize.
ROFL, I was just thinking that a script like that would be useful, should
have known I wouldn't be the first to think of it. I'll have to modify
it, or make the port depend on bash, since the function syntax used
doesn't work for FreeBSD's /bin/sh (or Solaris 2.6 /bin/sh for that
matter).
> > And how would one go about having multiple incoming identities? Say if I
> > generate a key for each workstation I'd be logging in from?
>
> You usually don't want to copy the private keys between machines.
Which is why I asked. For IPSec I don't mind using sneakernet to tranfer
keys.
> So
> you generate one keypair for each machine you want to log in from.
> Then copy each of the public keys to the machine you want to log in to
> and authorize them as above.
O.K., now I see what I was missing, the identity files are only used to
authenticate with another machine, it's the authorize stuff that is used
when connecting to the current machine, and you can have multiple
authorize files, no problem :-) (I'm usually not this slow, really :-)
