{"thread":{"id":"29258","subject":"GIT and SSH","startedAt":"2011-12-28T08:43:45Z","lastAt":"2011-12-29T03:06:29Z","messageCount":7,"participants":["Reza Mostafid","Dov Grobgeld","Carlos Martín Nieto","Jakub Narebski","Thomas Hochstein"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"181747","messageId":"loom.20111228T091942-66@post.gmane.org","threadId":"29258","inReplyTo":null,"subject":"GIT and SSH","fromName":"Reza Mostafid","fromEmail":"m.r.mostafid@gmail.com","sentAt":"2011-12-28T08:43:45Z","receivedAt":"2011-12-28T08:43:45Z","isPatch":false,"sender":{"key":"m.r.mostafid@gmail.com","avatar":null},"body":"I am starting to use GIT and I would be grateful for a simple answer to a\nspecific situation to help me find the right ball-park.\n\n\na.) Does the communication that takes place between a GIT `client` and a remote\n    GIT `repository` involve 'ssh' traffic?\n\n\nOur connections here are heavily censored and ssh traffic is suppressed most of\nthe time which is why I need to figure out why a simple  \n\n    $ git clone git://<URL> \n\ncommand chokes to a halt and freezes most of the time ( the same command when\nexecuted remotely on our V.P.S. in Europe works flawlessly ).\n \n\nb.) Are there means to make the `git` client on my machine circumvent this?\n\n\nY/N answers or brief hints to my questions suffice, I'll work out the rest. \n\nBasically I would like to know whether there is a point at all trying to make\ngit work from where I am, given the limitations mentioned.\n\nRegards\n\nReza\n"},{"id":"181748","messageId":"CA++fsGFOC6bV4gC+ozBKP3EmoAX4CcfTrHjjpMWPkh7vYOfgAw@mail.gmail.com","threadId":"29258","inReplyTo":"loom.20111228T091942-66@post.gmane.org","subject":"Re: GIT and SSH","fromName":"Dov Grobgeld","fromEmail":"dov.grobgeld@gmail.com","sentAt":"2011-12-28T09:55:24Z","receivedAt":"2011-12-28T09:55:24Z","isPatch":false,"sender":{"key":"dov.grobgeld@gmail.com","avatar":"https://gravatar.com/avatar/b74b57a9ce04ef5f356927856e125f1e70e7ce38772c5b8793b854b830f0fe6c?d=mp&s=160"},"body":"Git supports multiple transport protocols. Among them are git, ssh,\nand https. (You can also use direct file system access, but it is\nquestionable whether to call that a protocol). Each of the protocols\nhave their advantages and drawbacks. The git protocol is only used for\nreading, and not for writing, but is supposed to be very fast. The\ncommon firewall filtering of the git protocol port 9418 is another\nproblem. ssh is the prefered protocol for writing to a remote\nprotocol. But if ssh is filtered, then http/https may be used, which\nis very slow for large repositories, but it has the advantage that it\nis the least blocked protocol.\n\nFor more info see:\n\n    http://progit.org/book/ch4-1.html\n\nRegards,\nDov\n\n\nOn Wed, Dec 28, 2011 at 10:43, Reza Mostafid <m.r.mostafid@gmail.com> wrote:\n> I am starting to use GIT and I would be grateful for a simple answer to a\n> specific situation to help me find the right ball-park.\n>\n>\n> a.) Does the communication that takes place between a GIT `client` and a remote\n>    GIT `repository` involve 'ssh' traffic?\n>\n>\n> Our connections here are heavily censored and ssh traffic is suppressed most of\n> the time which is why I need to figure out why a simple\n>\n>    $ git clone git://<URL>\n>\n> command chokes to a halt and freezes most of the time ( the same command when\n> executed remotely on our V.P.S. in Europe works flawlessly ).\n>\n>\n> b.) Are there means to make the `git` client on my machine circumvent this?\n>\n>\n> Y/N answers or brief hints to my questions suffice, I'll work out the rest.\n>\n> Basically I would like to know whether there is a point at all trying to make\n> git work from where I am, given the limitations mentioned.\n>\n> Regards\n>\n> Reza\n>\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"},{"id":"181749","messageId":"20111228101512.GA2192@beez.lab.cmartin.tk","threadId":"29258","inReplyTo":"CA++fsGFOC6bV4gC+ozBKP3EmoAX4CcfTrHjjpMWPkh7vYOfgAw@mail.gmail.com","subject":"Re: GIT and SSH","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2011-12-28T10:15:12Z","receivedAt":"2011-12-28T10:15:12Z","isPatch":false,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"On Wed, Dec 28, 2011 at 11:55:24AM +0200, Dov Grobgeld wrote:\n> Git supports multiple transport protocols. Among them are git, ssh,\n> and https. (You can also use direct file system access, but it is\n> questionable whether to call that a protocol). Each of the protocols\n> have their advantages and drawbacks. The git protocol is only used for\n> reading, and not for writing, but is supposed to be very fast. The\n> common firewall filtering of the git protocol port 9418 is another\n> problem. ssh is the prefered protocol for writing to a remote\n> protocol. But if ssh is filtered, then http/https may be used, which\n> is very slow for large repositories, but it has the advantage that it\n> is the least blocked protocol.\n\nSlow for large repositories? Are you thinking of the dumb HTTP\ntransport? That one shouldn't be used for doing any serious work. The\nSmart HTTP transport is just the git smart protocol (the same one\ngit:// and ssh:// URLs speak) wrapped inside HTTP communication. The\nnegotiation phase is a more expensive than with either git or ssh, as\nHTTP is stateless and you need to remind the remote what you want and\nwhat you've already agreed on, but the actual transfer of data is done\nthe same way than with the others so overall it shouldn't be that\nnoticeable.\n\nNow, to the OP's concerns: yes, the ssh transport does generate ssh\ntransport, as that's the whole point. You authenticate against the\nremote machine's ssh daemon and run git-upload-pack or\ngit-receive-pack as needed (for fetching or pushing). If corporate\npolicy doesn't allow ssh you should either fix the policy or use the\nsmart HTTP protocol, though this involves messing with passwords and\ntheir associated problems. I'm not saying ssh keys don't have their\ncomplications, but I much prefer them.\n\nWe can't help you diagnose why your clone is stalling without more\ninformation. It could be that the connection between the computers is\nflaky, git trying to take too much memory on the remote or local\nmachines or any number of things. See if setting GIT_TRACE=1 in the\nenvironment helps to see what's going on.\n\n   cmn\n"},{"id":"181751","messageId":"loom.20111228T115814-404@post.gmane.org","threadId":"29258","inReplyTo":"loom.20111228T091942-66@post.gmane.org","subject":"Re: GIT and SSH","fromName":"Reza Mostafid","fromEmail":"m.r.mostafid@gmail.com","sentAt":"2011-12-28T11:01:58Z","receivedAt":"2011-12-28T11:01:58Z","isPatch":false,"sender":{"key":"m.r.mostafid@gmail.com","avatar":null},"body":"I forgot to mention, I am an embedded developer located in Iran.\n\nThe filtering I am talking about is by the government. All ISP's get their\nbandwith from centrally allocated trunks. This allows control.\n\nI know that ssh packets get dropped for extended periods frequently.\nWe have an Ubuntu virtual server outside of Iran which we use as a proxy and\nconnect to it via 'ssh' sox provxy ( -D 8090 ).\n\nMany times some sort of script or intelligence is operation which severely\nthrottles the connection as soon as the data rate exceeds certain \"benign\" \nlevels. All this has been confirmed by the network `gurus` and admin people I\nwork with. This is the best we can tell from what we observe.\n\nAs mentioned when we execute the simple GIT clone command from our VPS \n( located outside Iran ) the command works flawlessly.\n\nWhat I would be interested in is to somehow make git avoid using transport\nover ssh. The government censors are interested only in blocking people\naccessing illicit sites via S.O.X-5 or VPN. \n\nTo them anything over SSH is suspicious. If we could somehow update using a\nplain transport method, they couldn't care less about source code being sent to \nus.\n\nRegards\n\nReza\n"},{"id":"181752","messageId":"m38vlxez79.fsf@localhost.localdomain","threadId":"29258","inReplyTo":"20111228101512.GA2192@beez.lab.cmartin.tk","subject":"Re: GIT and SSH","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-12-28T11:02:40Z","receivedAt":"2011-12-28T11:02:40Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Carlos Martín Nieto <cmn@elego.de> writes:\n> On Wed, Dec 28, 2011 at 11:55:24AM +0200, Dov Grobgeld wrote:\n\n> > Git supports multiple transport protocols. Among them are git, ssh,\n> > and https. (You can also use direct file system access, but it is\n> > questionable whether to call that a protocol). Each of the protocols\n> > have their advantages and drawbacks. The git protocol is only used for\n> > reading, and not for writing, but is supposed to be very fast. The\n\nFYI git:// protocol can theoretically be used for pushing, but it is\nnot recommended because git:// protocol is not authenthicated - that\nis why you need to enable pushing via git:// explicitly.\n\nJust git trivia.\n\n> > common firewall filtering of the git protocol port 9418 is another\n> > problem. ssh is the prefered protocol for writing to a remote\n> > protocol. But if ssh is filtered, then http/https may be used, which\n> > is very slow for large repositories, but it has the advantage that it\n> > is the least blocked protocol.\n> \n> Slow for large repositories? Are you thinking of the dumb HTTP\n> transport? That one shouldn't be used for doing any serious work. The\n> Smart HTTP transport is just the git smart protocol (the same one\n> git:// and ssh:// URLs speak) wrapped inside HTTP communication. The\n> negotiation phase is a more expensive than with either git or ssh, as\n> HTTP is stateless and you need to remind the remote what you want and\n> what you've already agreed on, but the actual transfer of data is done\n> the same way than with the others so overall it shouldn't be that\n> noticeable.\n\nNote that for \"smart\" transports (\"smart\" HTTP, SSH) you need to have\ngit installed on server, or at least have git-upload-pack and\ngit-receive-pack somewhere (you can configure client where it is to be\nfound on server).\n \nNote that git uses curl for both smart and dumb HTTP transports, so\nthings like 'http_proxy' and 'HTTPS_PROXY' environment variables\nshould work.\n\n> Now, to the OP's concerns: yes, the ssh transport does generate ssh\n> transport, as that's the whole point. You authenticate against the\n> remote machine's ssh daemon and run git-upload-pack or\n> git-receive-pack as needed (for fetching or pushing). If corporate\n> policy doesn't allow ssh you should either fix the policy or use the\n> smart HTTP protocol, though this involves messing with passwords and\n> their associated problems. I'm not saying ssh keys don't have their\n> complications, but I much prefer them.\n\nNote that if the problem is giving shell accounts with SSH access, the\nsolution is to use one of git repository management tools, like\nGitosis (Python + setuptools, no longer developed) or Gitolite (Perl).\nFrom what I remember both use _single_ *restricted* account and\npublic-key authenthication.\n \nIf I am not mistaken Gitolite can help with \"smart\" HTTP transport\naccess too.\n\n> We can't help you diagnose why your clone is stalling without more\n> information. It could be that the connection between the computers is\n> flaky, git trying to take too much memory on the remote or local\n> machines or any number of things. See if setting GIT_TRACE=1 in the\n> environment helps to see what's going on.\n\nOr even undocumented (!) GIT_TRACE_PACKET.\n\n-- \nJakub Narebski\n"},{"id":"181759","messageId":"gcvg.1112281234.3780@landroval.ancalagon.de","threadId":"29258","inReplyTo":"loom.20111228T091942-66@post.gmane.org","subject":"Re: GIT and SSH","fromName":"Thomas Hochstein","fromEmail":"thh@inter.net","sentAt":"2011-12-28T11:34:42Z","receivedAt":"2011-12-28T11:34:42Z","isPatch":false,"sender":{"key":"thh@inter.net","avatar":"https://avatars.githubusercontent.com/u/365129?v=4"},"body":"Reza Mostafid schrieb:\n\n> a.) Does the communication that takes place between a GIT `client` and a remote\n>     GIT `repository` involve 'ssh' traffic?\n\nDepends on how you do it (as already described by others).\n\n> Our connections here are heavily censored and ssh traffic is suppressed most of\n> the time which is why I need to figure out why a simple  \n>\n>     $ git clone git://<URL> \n>\n> command chokes to a halt and freezes most of the time ( the same command when\n> executed remotely on our V.P.S. in Europe works flawlessly ).\n\n\"git://\" uses the git protocol which does not involve SSH.\n\n    $ git clone ssh://<URL>\n\nwould use SSH.\n\n-thh\n"},{"id":"181771","messageId":"loom.20111229T040526-145@post.gmane.org","threadId":"29258","inReplyTo":"loom.20111228T091942-66@post.gmane.org","subject":"Re: GIT and SSH","fromName":"Reza Mostafid","fromEmail":"m.r.mostafid@gmail.com","sentAt":"2011-12-29T03:06:29Z","receivedAt":"2011-12-29T03:06:29Z","isPatch":false,"sender":{"key":"m.r.mostafid@gmail.com","avatar":null},"body":"Thanks for all the feedback so far.....helps me find out where to look.\n\nRegards\n\nReza\n"}]}