Sylvain BERTRAND <[email protected]> writes: > How do you use lsh with git?
I set the GIT_SSH environment variable to lsh or lshg. > For my part, there is what I did: Which version of lsh are you using, I guess 2.1? > - I created a ssh symbolic link to lsh. Should work. Or use GIT_SSH. I don't know if there's any way to configure the ssh program to use with git config. > - I worked around the [user@] URL parsing using the LOGNAME environnment > variable. And that syntax is translated to a user@host argument to lsh? I understand that this helps with git, since git@host is common with git servers, including [email protected]:/lsh/lsh.git. It is supported in the development version of lsh. > (It seems git URLs with ~user expansion do not work neither) Can you give some more details? The actual expansion ought to be done at the server end, I guess? > - I created specific lsh key pairs, due to the private key export/import > "limitations" (actually, the private key format mess, lol). Right, private keys are not supposed to be passed around, hence are considered out of scope for ssh standardization. But even if not copied between machines, some interoperability between different implementations on a single machine would be nice. > I may have a different key pair for each git repository, hence, does > the -i option finally work? What's the problem with -i? That you can pass only one? There are two problems here, first is that the option parsing wants only a single identity. Second is that lsh reads the private key file only, and if it's encrypted, it has no idea what the public key is until you have typed in the right passphrase. Which means that it can't negotiate which key to use with the server until after the passphrase. Ideally, one should use a key format that includes both the public key, unencrypted, and the necrypted private key. Or read the .pub file too and hope the two files match. > (with git I'll use the flags related environment variable to pass the several > -i options) I think the easiest way to get going with current lsh is to first connect and authenticate to the server using lsh -B -G -i key-file -l user host and then export GIT_SSH=lshg. I don't plan to add features to the 2.x branch, and I'd really like to get lsh-3 out (but that's a pretty slow process, i'm afraid). But it would make some sense to backport simple things, like supporting user@host (in the development version, this is in https://git.lysator.liu.se/lsh/lsh/blob/master/src/lsh.c, function main_argp_parser, and to backport that, the right place is https://git.lysator.liu.se/lsh/lsh/blob/lsh-2.0.4/src/client.c, function client_argp_parser). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. _______________________________________________ lsh-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/lsh-bugs
