Hi,
How do you use lsh with git?
For my part, there is what I did: - I created a ssh symbolic link to lsh. - I worked around the [user@] URL parsing using the LOGNAME environnment variable. (It seems git URLs with ~user expansion do not work neither) - I created specific lsh key pairs, due to the private key export/import "limitations" (actually, the private key format mess, lol).
I may have a different key pair for each git repository, hence, does the -i option finally work? (with git I'll use the flags related environment variable to pass the several -i options)
best regards,
Sylvain BERTRAND sylvain.bertrand@gmail.com 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 git@git.lysator.liu.se:/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
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!!!
Sylvain BERTRAND sylvain.bertrand@gmail.com writes:
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 :(
I don't think it is documented in any obvious place, like git help clone which describes the various types of git urls.
strings /usr/bin/git |grep GIT_
gives a list including a bunch of environment variables...
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).
For what it's worth, the development version no longer uses automake. But it still uses autoconf (which I like), which also depends on perl these days.
Does it maintain a permanent connexion to the server?
Exactly, lsh -G enables "gateway mode". In openssh, the same thing is called connection sharing, I think.
Regards, /Niels
On Thu, Dec 18, 2014 at 12:49:28PM +0100, Niels Möller wrote:
strings /usr/bin/git |grep GIT_
gives a list including a bunch of environment variables...
I was too naive: glimpsing the environment section of a few man pages was not good enough.
For what it's worth, the development version no longer uses automake. But it still uses autoconf (which I like), which also depends on perl these days.
Good ridance of automake. Autoconf now pulls perl5?! Kludge on kludge on more kludge... nervously tiring.
BTW, I saw you switched to gitlab.com for the git repository... unfortunately, it seems gitlab switched to their proprietary edition for gitlab.com...
-
nisse＠lysator.liu.se -
Sylvain BERTRAND