G'day openssh-unix-dev, is there a way to unset a 'SendEnv' given by /etc/ssh/ssh_config? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20180703/b93c146e/attachment.asc>
On Tue, 3 Jul 2018, Martin Drescher wrote:> G'day openssh-unix-dev, > > is there a way to unset a 'SendEnv' given by /etc/ssh/ssh_config?HEAD has the ability to clear one using SendEnv=-FOO, but I'm toying with the idea of breaking backwards compatibility and making SendEnv behave like the rest of the options and be first match wins. What do you all think? -d
Hi Damien, let me tell you where I'm coming from: I have a bunch of machines. Sometimes, localisation is incomplete or broken or messed up in a different way. Straight way would be to unset LC_* in a remote bashrc. But this sucks, because of cloud hosting, automated deployment, IaaS... you know where I'm going. I would like to do this in .ssh/config, per host. So, my best idea would be to put something like 'export MY_VAR=' in place. This is quite close to a 'SendEnv=-FOO' idea (or 'unset' in bash terms) but adds even more flexibility. Am 04.07.2018 um 11:27 schrieb Damien Miller:> On Tue, 3 Jul 2018, Martin Drescher wrote: > >> G'day openssh-unix-dev, >> >> is there a way to unset a 'SendEnv' given by /etc/ssh/ssh_config? > > HEAD has the ability to clear one using SendEnv=-FOO, but I'm toying > with the idea of breaking backwards compatibility and making SendEnv > behave like the rest of the options and be first match wins. > > What do you all think? > > -d >Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20180704/7187d232/attachment.asc>
Hi Damien,> HEAD has the ability to clear one using SendEnv=-FOO, but I'm toying > with the idea of breaking backwards compatibility and making SendEnv > behave like the rest of the options and be first match wins. > > What do you all think?Oh no, please don't. Allowing multiple SendEnv lines makes it much easier to automatically (and manually!) check and fix the configuration - a simple if ! grep ... ; then echo ... >> ... ; fi is good enough to get some known-good lines into sshd_config. Visually it's easier to see the common, expected patterns than to look at a line of indeterminate length as well. So yes, SendEnv=-FOO sounds good to me.