Por que um comando remoto SSH obtém menos variáveis ​​de ambiente quando executado manualmente? [fechadas]

Eu tenho um comando que roda bem se eu ssh em uma máquina e a executo, mas falha quando tento executá-la usando um comando ssh remoto como:

ssh user@IP <command>

Comparando a saída de "env" usando os dois métodos, resutls em diferentes ambientes. Quando efetuo login manualmente na máquina e executo env, recebo muito mais variáveis ​​de ambiente do que quando executo:

ssh user@IP "env"

Alguma idéia do porquê?

Existem diferentes tipos de conchas. O shell de execução do comando SSH é um shell não interativo, enquanto o seu shell normal é um shell de logon ou um shell interativo. Descrição a seguir, do man bash:

       Um shell de login é aquele cujo primeiro caractere de argumento
       zero é um - ou foi iniciado com a opção --login.

       Um shell interativo é aquele iniciado sem opção
       argumentos e sem a opção -c cuja entrada padrão
       e erro estão conectados aos terminais (conforme determinado
       por isatty (3)) ou um iniciado com a opção -i. PS1 é
       set e $ - inclui i se o bash for interativo, permitindo uma
       shell script ou um arquivo de inicialização para testar esse estado.

       Os parágrafos a seguir descrevem como o bash executa sua
       arquivos de inicialização. Se algum dos arquivos existir, mas não puder ser
       ler, bash relata um erro. Tildes são expandidos em arquivo
       nomes descritos abaixo em Expansão Tilde no
       Seção de expansão.

       Quando o bash é chamado como um shell de logon interativo ou como
       um shell não interativo com a opção --login, primeiro
       lê e executa comandos do arquivo / etc / profile, se
       esse arquivo existe. Depois de ler esse arquivo, ele procura
       ~ / .bash_profile, ~ / .bash_login e ~ / .profile, nesse
       ordem e lê e executa comandos desde o primeiro
       que existe e é legível. A opção --noprofile pode
       ser usado quando o shell for iniciado para inibir esse comportamento
       eu ou.

       Quando um shell de login sai, o bash lê e executa comandos
       do arquivo ~ / .bash_logout, se existir.

       Quando um shell interativo que não é um shell de logon é
       iniciado, o bash lê e executa comandos de ~ / .bashrc,
       se esse arquivo existir. Isso pode ser inibido usando o
       opção --norc. A opção de arquivo --rcfile forçará o bash
       para ler e executar comandos do arquivo em vez de
       ~ / .bashrc.

       Quando o bash é iniciado de maneira não interativa, para executar um shell
       script, por exemplo, procura a variável BASH_ENV em
       ambiente, expande seu valor se aparecer lá,
       e usa o valor expandido como o nome de um arquivo para ler
       e executar. O bash se comporta como se o seguinte comando
       foram executados:
              if [-n "$ BASH_ENV"]; então . "$ BASH_ENV"; fi
       mas o valor da variável PATH não é usado para procurar
       para o nome do arquivo.

Que tal obter o perfil antes de executar o comando?

ssh user@host "source /etc/profile; /path/script.sh"

Você pode achar que é melhor para mudar isso para ~/.bash_profile, ~/.bashrcou o que quer.

(Como aqui (linuxquestions.org) )

O ambiente do shell não carrega ao executar o comando ssh remoto. Você pode editar o arquivo de ambiente ssh:

vi ~/.ssh/environment

Seu formato é:

VAR1=VALUE1
VAR2=VALUE2

Além disso, verifique a sshdconfiguração para a PermitUserEnvironment=yesopção.

Eu tive um problema semelhante, mas no final descobri que ~ / .bashrc era tudo que eu precisava.

No entanto, no Ubuntu, tive que comentar a linha que para de processar ~ / .bashrc:

#If not running interactively, don't do anything
[ -z "$PS1" ] && return

Encontrei uma solução fácil para esse problema: adicionar código-fonte / etc / profile à parte superior do arquivo script.sh que eu estava tentando executar no sistema de destino. Nos sistemas aqui, isso fez com que as variáveis ​​ambientais necessárias ao script.sh fossem configuradas como se estivessem sendo executadas a partir de um shell de login.

Em uma das respostas anteriores, sugeriu-se que ~ / .bashr_profile etc ... fosse usado. Não gastei muito tempo com isso, mas o problema é que se você fizer um shsh para um usuário diferente no sistema de destino do que o shell no sistema de origem no qual você efetua login, me pareceu que isso causa o usuário do sistema de origem nome a ser usado para o ~.

Apenas exporte as variáveis ​​de ambiente que você deseja acima da verificação para um shell não interativo em ~ / .bashrc.