Timshel Knoll <[EMAIL PROTECTED]> writes:

> What I've done is the following:
> 1. ssh2-keygen on the uni box to create key pair
> 2. copy public key to home box
> 3. ssh-conv < my_uni_ssh2_key.pub > my_uni_lsh_format_ssh_key.pub
> 4. lsh-authorize my_uni_lsh_format_ssh_key.pub

At least, that's the recommended procedure.

> However, public key auth still doesn't work, I am asked for a password.
> Have I missed something obvious? I haven't had any problems with OpenSSH
> 3.0 -> lshd, and I followed the same process as above. Attached is the
> output of lshd -v, lshd --trace and lshd --debug. Any ideas?

Hard to say, looking at the debug log, the client sends two userauth
requests (the contents of which are censored in the log), to which
lshd responds with a userauth failure, and indicates that the client
can try either password or public-key. You could try setting a
breakpoint on server_userauth.c:do_handle_userauth in lshd and see
what happens.

lshd contains no bug-compatibility hacks for SSH-3.x, if the bugs in
earlier versions haven't been fixed, workarounds have to be
enabled in handshake.c. The flags that might be relevant are

    /* Use a different encoding of ssh-dss signatures, for
     * compatibility with SSH Inc's ssh version 2.0.x and 2.1.0 */
    PEER_SSH_DSS_KLUDGE          = 0x00000001,
    
    /* Replace the service name with the string "ssh-userauth" in
     * publickey userauth requests, for compatibility with SSH Inc's
     * ssh version 2.0.x and 2.1.0 */
    PEER_USERAUTH_REQUEST_KLUDGE = 0x00000004,

The configuration of workarounds is a little cleaner in my current
code than in 1.2.5 or 1.3.6.

Hmm, are you using an rsa or a dsa key? The first flag above (and the
corresponding bug) isn't relevant for rsa, of course.

Regards,
/Niels

Reply via email to