openssh unix dev - Jul 2018 - Unset a given SendEnv?

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.