On Wed, Dec 17, 2014 at 09:20:11PM +0100, Niels Möller wrote:
I set the GIT_SSH environment variable to lsh or lshg.
I wonder how I have managed to miss that :(
Which version of lsh are you using, I guess 2.1?
Yes. I use released version to avoid having automake(perl5) installed on my custom distro (or other super kludges).
Can you give some more details? The actual expansion ought to be done at the server end, I guess?
I have not digged that deep, then I have no idea if it's client side or server side.
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.
The thing is to have something like ssh-agent. But it's fine using the *FLAGS environment variable to switch of key pair.
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.
Does it maintain a permanent connexion to the server? If so, server admnins won't like it :)
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).
I'll manage till your next release.
thx!!!