come disabilitare le variabili SendEnv impostate in ssh_config da ~ / .ssh / config


30

Non riuscivo a trovarlo da nessuna parte, quindi mi chiedo se sono l'unico a colpire un simile problema.

Per impostazione predefinita, ssh su Red Hat e Debian ha almeno un ssh_config con l'opzione SendEnv che passa le variabili LC * e LANG nella sessione remota. Se uno non è root per cambiare / etc / ssh / ssh_config, come può disabilitare quel comportamento? L'opzione SendEnv sembra accumularsi e non riesco a vedere alcun modo per ripristinarlo.

E per evitare che mi venga chiesto, devo evitare di passare la mia locale alle macchine di prova per evitare effetti collaterali su script e programmi che si basano sulla locale come predefinita per la macchina.


Questa non è una risposta alla tua domanda, ma puoi risolvere il tuo problema invocando gli script e i programmi sui tuoi computer di prova attraverso envo con uno script wrapper?
Scott,

2
sì, le soluzioni alternative sono possibili ma scomode
Akostadinov

Risposte:


18

Non sei l'unico . Come documentato in, ssh_config(5)non è possibile annullare l'impostazione SendEnv, perché

Più variabili di ambiente possono [...] essere distribuite su più direttive SendEnv.

Se hai root sui computer di prova, puoi cambiare AcceptEnvper non accettare le variabili inviate dal client.


4
merda, vedo solo -F nella riga di comando può aiutare, ma è troppo scomodo da usare davvero. Vedi bugzilla.mindrot.org/show_bug.cgi?id=1285
akostadinov

5

Questo non può essere fatto ~/.ssh/configperché SendEnvnon può essere ignorato.

L'uso degli alias non funzionerà per gli script che chiamano ssh.

Un'alternativa è esportare una funzione. Ad esempio ~/.bashrc:

function ssh() {
    LANG="en_US.UTF-8" \
    LC_ADDRESS="$LANG" \
    LC_IDENTIFICATION="$LANG" \
    LC_MEASUREMENT="$LANG" \
    LC_MONETARY="$LANG" \
    LC_NAME="$LANG" \
    LC_NUMERIC="$LANG" \
    LC_PAPER="$LANG" \
    LC_TELEPHONE="$LANG" \
    LC_TIME="$LANG" \
    LC_ALL="$LANG" \
    /usr/bin/ssh $@
}
export -f ssh

1

C'è un'opzione SetEnv, si può forzare LANGa un valore specifico prima di inviarlo.

Anche la pagina man lo dice

È possibile cancellare i nomi delle variabili SendEnv precedentemente impostati prefissando i pattern con -.

ma non sono riuscito a farlo funzionare.


Vedi bugzilla.mindrot.org/show_bug.cgi?id=1285 , probabilmente questo spiegherà perché l' -approccio non ha funzionato. Un buon consiglio però di codificare a distanza LANG remoto e altri vars in ssh config. Rende le cose più prevedibili. Forse SetEnvè una direttiva più recente perché nessun altro l'ha suggerito. SetEnv LANG=en_US.UTF-8
Akostadinov

0

Se stai usando bash puoi impostare un alias ssh = 'LANG = comando ssh' per disabilitare il passaggio di LANG agli altri server.


0

Puoi usare su - youruser quando si è effettuato l'accesso tramite ssh. Ciò reinizializzerà l'ambiente per l'utente.

In realtà si inizializza una nuova sessione con un nuovo ambiente.


La domanda è avere l'ambiente sano automaticamente. E btw su non è sempre installato. E devi digitare la password con su. Inutile. Esistono soluzioni alternative più facili.
Akostadinov,

0

Secondo man ssh:

 -F configfile
         Specifies an alternative per-user configuration file.  If a con-
         figuration file is given on the command line, the system-wide
         configuration file (/etc/ssh/ssh_config) will be ignored.  The
         default for the per-user configuration file is ~/.ssh/config.

Quindi, puoi ssh senza rispettare/etc/ssh/ssh_config specificando esplicitamente il file di configurazione (predefinito) sulla riga di comando ( ~/.ssh/configva bene essere vuoto):

$ touch ~/.ssh/config
$ ssh -F ~/.ssh/config your_user@your_host

Puoi creare un alias per questo in ~/.bashrc:

alias ssh="ssh -F ~/.ssh/config"

Riavvia la shell bash, quindi puoi semplicemente ssh in questo modo:

$ ssh your_user@your_host

Vedi il mio commento sopra. if one supplies on command line -F, then the system wide config is ignored according to man pageda bugzilla.mindrot.org/show_bug.cgi?id=1285 ; è un'opzione ma non proprio la funzionalità desiderata.
Akostadinov,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.