{"thread":{"id":"56065","subject":"Default ssh command","startedAt":"2021-07-07T01:36:09Z","lastAt":"2021-07-08T13:51:38Z","messageCount":5,"participants":["Aaron Hall","Junio C Hamano","brian m. carlson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"429386","messageId":"CADrEZfE+LuDnhWkRHPMwHq7aGYcvDeqken8uZzPgHREtf0iqjA@mail.gmail.com","threadId":"56065","inReplyTo":null,"subject":"Default ssh command","fromName":"Aaron Hall","fromEmail":"aaronchallmba@gmail.com","sentAt":"2021-07-07T01:35:30Z","receivedAt":"2021-07-07T01:36:09Z","isPatch":false,"sender":{"key":"aaronchallmba@gmail.com","avatar":null},"body":"I was trying to push some binary files (PNGs) over ssh and found some\nfiles inexplicably wouldn't successfully push.\n\nI set, in my .gitconfig file:\n\n[core]\n sshCommand = ssh -e none\n\nAnd it works now for all files (that I can tell).\n\nFrom a close examination of the output where I noted escape codes\nshowing up, I believe the problem to be ssh escape codes.\n\n`\\n~.` for example closes the ssh client.\n\nTherefore I think the default ssh command should be `ssh -e none`\ninstead of `ssh` for the benefit of users who won't recognize the\nproblem, unless `git` is expected to make use of ssh escape codes.\n\nI'm new to the mailing list, sorry if I missed some protocol here.\nThank you so much for working on `git` and making your work\n available to the rest of the world. Cheers!\n"},{"id":"429388","messageId":"xmqqczrugahy.fsf@gitster.g","threadId":"56065","inReplyTo":"CADrEZfE+LuDnhWkRHPMwHq7aGYcvDeqken8uZzPgHREtf0iqjA@mail.gmail.com","subject":"Re: Default ssh command","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-07-07T01:48:09Z","receivedAt":"2021-07-07T01:48:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Aaron Hall writes:\n\n> I was trying to push some binary files (PNGs) over ssh and found some\n> files inexplicably wouldn't successfully push.\n>\n> I set, in my .gitconfig file:\n>\n> [core]\n> sshCommand = ssh -e none\n>\n> And it works now for all files (that I can tell).\n>\n> From a close examination of the output where I noted escape codes\n> showing up, I believe the problem to be ssh escape codes.\n>\n> `\\n~.` for example closes the ssh client.\n>\n> Therefore I think the default ssh command should be `ssh -e none`\n> instead of `ssh` for the benefit of users who won't recognize the\n> problem, unless `git` is expected to make use of ssh escape codes.\n\nCurious. \n\nWhen we use ssh to run the receive-pack over the wire while pushing,\nwe do not ask for pty, and because the \"-e\" option to set the escape\ncharacter is meaningful only when ssh runs with pty allocated, you\nshouldn't have to do this, unless you force pty allocation by\ne.g. passing \"-t\" yourself.\n"},{"id":"429390","messageId":"CADrEZfEVbtbovTbFM2BEuK_cWp4jcV3CZyrzasvsvFbuu1rmWg@mail.gmail.com","threadId":"56065","inReplyTo":"CADrEZfHJZT47nNZJ8v2T4vOJkMN7ccaai6DKdzFLF8Zoc42hWw@mail.gmail.com","subject":"Re: Default ssh command","fromName":"Aaron Hall","fromEmail":"aaronchallmba@gmail.com","sentAt":"2021-07-07T02:13:34Z","receivedAt":"2021-07-07T02:14:16Z","isPatch":false,"sender":{"key":"aaronchallmba@gmail.com","avatar":null},"body":"> When we use ssh to run the receive-pack over the wire while pushing,\n> we do not ask for pty, and because the \"-e\" option to set the escape\n> character is meaningful only when ssh runs with pty allocated, you\n> shouldn't have to do this, unless you force pty allocation by\n> e.g. passing \"-t\" yourself.\n\nThen I wonder why I'm getting a pseudoterminal.\n\nNote that I'm using git from git bash on Windows in a walled off\ncorporate environment.\n\nThe ssh manpage says:\n\n> If no pseudo-terminal has been allocated, the session is transparent\n> and can be used to reliably transfer binary data. On most\n> systems, setting the escape character to ``none'' will also\n> make the session transparent even if a tty is used.\n\nIf we want the ssh to be binary transparent regardless\n(and I think we do) then that makes my suggestion,\n`ssh -e none`, still perhaps a good one?\n\nOn Tue, Jul 6, 2021 at 10:03 PM Aaron Hall wrote:\n>\n> I'll reply on list.\n>\n> On Tue, Jul 6, 2021 at 9:58 PM Aaron Hall wrote:\n> >\n> > My context is using git from git bash on Windows in a walled off environment.\n> >\n> > On Tue, Jul 6, 2021 at 9:48 PM Junio C Hamano wrote:\n> > >\n> > > Aaron Hall writes:\n> > >\n> > > > I was trying to push some binary files (PNGs) over ssh and found some\n> > > > files inexplicably wouldn't successfully push.\n> > > >\n> > > > I set, in my .gitconfig file:\n> > > >\n> > > > [core]\n> > > > sshCommand = ssh -e none\n> > > >\n> > > > And it works now for all files (that I can tell).\n> > > >\n> > > > From a close examination of the output where I noted escape codes\n> > > > showing up, I believe the problem to be ssh escape codes.\n> > > >\n> > > > `\\n~.` for example closes the ssh client.\n> > > >\n> > > > Therefore I think the default ssh command should be `ssh -e none`\n> > > > instead of `ssh` for the benefit of users who won't recognize the\n> > > > problem, unless `git` is expected to make use of ssh escape codes.\n> > >\n> > > Curious.\n> > >\n> > > When we use ssh to run the receive-pack over the wire while pushing,\n> > > we do not ask for pty, and because the \"-e\" option to set the escape\n> > > character is meaningful only when ssh runs with pty allocated, you\n> > > shouldn't have to do this, unless you force pty allocation by\n> > > e.g. passing \"-t\" yourself.\n"},{"id":"429421","messageId":"YOWsNk4GqNUPyHD5@camp.crustytoothpaste.net","threadId":"56065","inReplyTo":"CADrEZfEVbtbovTbFM2BEuK_cWp4jcV3CZyrzasvsvFbuu1rmWg@mail.gmail.com","subject":"Re: Default ssh command","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-07-07T13:29:26Z","receivedAt":"2021-07-07T13:29:35Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-07-07 at 02:13:34, Aaron Hall wrote:\n> > When we use ssh to run the receive-pack over the wire while pushing,\n> > we do not ask for pty, and because the \"-e\" option to set the escape\n> > character is meaningful only when ssh runs with pty allocated, you\n> > shouldn't have to do this, unless you force pty allocation by\n> > e.g. passing \"-t\" yourself.\n> \n> Then I wonder why I'm getting a pseudoterminal.\n> \n> Note that I'm using git from git bash on Windows in a walled off\n> corporate environment.\n\nDo you maybe have RequestTTY set in some SSH configuration file, like\n~/.ssh/config? You can also run \"ssh -vvv HOSTNAME\" to see if there are\nany config files.\n\nFor example, if I do \"ssh -vvv git@github.com\"[0], I see these lines:\n\n debug1: Reading configuration data /home/bmc/.ssh/config\n debug1: /home/bmc/.ssh/config line 44: Applying options for github.com\n debug1: /home/bmc/.ssh/config line 67: Applying options for *\n debug3: kex names ok: [sntrup4591761x25519-sha512@tinyssh.org,curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256]\n debug1: Reading configuration data /etc/ssh/ssh_config\n debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files\n debug1: /etc/ssh/ssh_config line 21: Applying options for *\n\nThat tells me I have some configuration for github.com (and for all\nhosts) in ~/.ssh/config and some for all hosts in /etc/ssh/ssh_config.\nIt doesn't tell me what they are, but I can look in the files to see.\n\nAlso, you may wish to run \"env | grep '^GIT'\" to see if anybody has\nconfigured the GIT_SSH or GIT_SSH_COMMAND variables, and check with \"git\nconfig -l --show-origin\" to see if someone has overridden the SSH\nconfiguration.\n\n> The ssh manpage says:\n> \n> > If no pseudo-terminal has been allocated, the session is transparent\n> > and can be used to reliably transfer binary data. On most\n> > systems, setting the escape character to ``none'' will also\n> > make the session transparent even if a tty is used.\n> \n> If we want the ssh to be binary transparent regardless\n> (and I think we do) then that makes my suggestion,\n> `ssh -e none`, still perhaps a good one?\n\nThe problem is that on some systems \"ssh\" is something other than\nOpenSSH and we will likely break those systems. That doesn't mean we\ncan't do it if it's necessary, but it does mean that if this is a\nconfiguration issue, it would be better to fix the configuration if we\ncan rather than potentially break systems needlessly.\n\nThis problem will also occur for tools like rsync and various other\nprograms which expect the standard behavior for the ssh binary, so\nmaking a change here in Git is also not the right place if we can avoid\nit.\n\n[0] Chosen simply because I know it works, it has configuration on my\nsystem, and it's publicly accessible.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"429489","messageId":"CADrEZfEzCzB1wq5_FaqH-pSK6vqYXXF0LFbXZ8fPKX_Mfr3QBw@mail.gmail.com","threadId":"56065","inReplyTo":"YOWsNk4GqNUPyHD5@camp.crustytoothpaste.net","subject":"Re: Default ssh command","fromName":"Aaron Hall","fromEmail":"aaronchallmba@gmail.com","sentAt":"2021-07-08T13:50:58Z","receivedAt":"2021-07-08T13:51:38Z","isPatch":false,"sender":{"key":"aaronchallmba@gmail.com","avatar":null},"body":"> Do you maybe have RequestTTY set in some SSH configuration file, like\n> ~/.ssh/config? You can also run \"ssh -vvv HOSTNAME\" to see if there are\n> any config files.\n\nThat's it! Not sure why I put a wildcard RequestTTY force... I was probably\njust going through the man page and putting down things that looked like\nwere what I wanted...\n\nMy urgency on this issue is gone. But unless git expects escape codes,\nperhaps it still should set them to none.\n\n> The problem is that on some systems \"ssh\" is something other than\n> OpenSSH and we will likely break those systems. That doesn't mean we\n> can't do it if it's necessary, but it does mean that if this is a\n> configuration issue, it would be better to fix the configuration if we\n> can rather than potentially break systems needlessly.\n\nI would expect it would be a compatible change but I don't have time\nto research it.\n\n> This problem will also occur for tools like rsync and various other\n> programs which expect the standard behavior for the ssh binary, so\n> making a change here in Git is also not the right place if we can avoid\n> it.\n\nTo me, it's weird that an improperly configured tool breaks another\ntool, and it seems that we could be more robust to that sort of\nproblem without breaking anyone, but as you say we would need to\nverify we're not breaking anyone.\n\nI suggest keeping this open as an issue, but that's up to you all.\n"}]}