mercurial - hg clone through a login server using ssh -
i'm trying collaborate individuals not in institution , not allowed connect internal network through vpn, however, ssh through login server allowed.
i.e. collaborates can login using 2 successive ssh commands:
$ ssh loginserver $ ssh repositoryserver after logging in can begin developing on repository server. however, make clone, , make modifications remotely, , push changes back.
i know 1 can run mercerial commands through ssh, , works fine me (because on network). i.e.:
$ hg clone ssh://uid@repositoryserver//path/to/repo however, there way run commands through login server?
something like:
$ hg clone ssh://uid@loginserver ssh://uid@repositoryserver//path/to/repo thanks help.
this in principle possible, underlying ssh chaining necessity bit fragile; if institution's policies allow hosting on external server, i'd consider option first.
that said, yes, can done. first of all, users need login repository server login server @ least once (if have restricted setup, cloning hg repository once – and throwing away – work). set entry repository server in ~/.ssh/known_hosts, necessary ssh chaining proceed without user prompts. if repository's server ssh configuration ever changes, entry become invalid , have repeat process after removing entry ~/.ssh/known_hosts or removing ~/.ssh/known_hosts entirely.
second, need enable authentication agent forwarding on machine (because otherwise they'll prompted password or pass phrase, won't able enter that). that, can 1 of following:
add entry ~/.ssh/config such as:
host lserve user uid hostname loginserver forwardagent true the alternative approach tell mercurial use agent forwarding adding following entry ~/.hgrc or .hg/hgrc:
[ui] ssh = ssh -a the downside doing in global ~/.hgrc agent forwarding done every repository, including ones may not want that. setting ~/.ssh/config cleaner option , allows simplify repo urls.
you can use --ssh "ssh -a" command line option, that's lot of typing.
depending on how write repo urls, other configurations may work better. above allow use of ssh://lserver//path/to/repo urls. critical part forwardagent true line, means remote server query local machine authentication, rather demanding password or pass phrase. needless say, means need have ssh agent authentication set locally.
next, have create shell script on loginserver forwards actual hg request. can put wherever (let's assume in /path/to/forward-hg:
#!/bin/sh ssh repositoryserver hg "$@" once done, friends can access remote repository follows:
hg clone --remotecmd /path/to/forward-hg ssh://lserve//path/to/repo hg push --remotecmd /path/to/forward-hg hg pull --remotecmd /path/to/forward-hg hg incoming --remotecmd /path/to/forward-hg hg outgoing --remotecmd /path/to/forward-hg because lot of typing, may want create aliases or put entry in local .hg/hgrc (caution: cannot done hg clone, still have type out or create, say, hg rclone alias). entry be:
[ui] remotecmd = /path/to/forward-hg and tell mercurial add requisite --remotecmd option commands support , operate on repository (note: not put entry in user's ~/.hgrc, in repository-specific one).
finally, here why works: when accessing remote repository, mercurial try start $remotehg serve --stdio (where $remotehg remote mercurial executable) , communicate process on stdin , stdout. hijacking $remotehg, becomes ssh repositoryserver hg serve --stdio, on repository server instead. meanwhile – assuming agent forwarding setup properly, password prompts , don't in way – the local mercurial client remain unaware of , see normal communication repository server on stdin , stdout (which passed through unaltered ssh daemon on login server).
Comments
Post a Comment