SSH - define env vairables por todas as conexões - godaddy shared host


16

Meu problema é que eu tenho que definir variáveis ​​env (como GIT_EXEC_PATH) em um servidor. Eu preciso dessas variáveis ​​por todas as conexões (por bash e por comandos remotos). Consegui definir essas variáveis ​​bash com .bash_profile, mas tenho problemas com os comandos remotos. Descobri que é possível escrever comandos em ~ / .ssh / allowed_keys antes da chave rsa real, mas não quero escrever sempre, preciso de uma solução permanente ... descobri que o ~ / .ssh O arquivo / rc é executado por todo login do ssh, então coloquei lá minhas declarações de variáveis ​​env, mas não funcionou. As variáveis ​​são definidas no arquivo rc, mas depois desaparecem. : S Talvez o arquivo rc seja executado em um subshell: S Existe alguma maneira de definir essas variáveis ​​no bash e em comandos remotos sem duplicação de código?

Editar:

Eu editei a pergunta, porque o servidor é um host compartilhado, então ele tem uma configuração exclusiva. Os arquivos / etc / ssh / sshd_config e / etc / ssh / ssh_config estão vazios. Existem comentários nesses arquivos, se você estiver curioso, posso copiá-lo aqui.

  1. O ~ / .bash_profile é originado (somente por conexões bash),
  2. o ~ / .bashrc nunca é originado,
  3. o perfil ~ /. nunca é originado,
  4. o ambiente ~ / .ssh / nunca é originado,
  5. o ~ / .ssh / rc é originário (por bash e remoto), mas acho que é chamado subshell, porque as variáveis ​​desaparecem.
  6. As ~ / .ssh / allowed_keys são originadas sempre, mas eu tenho que escrever os comandos antes de cada chave rsa (para que eu não queira configurar com isso).

Resumo:

Posso configurar bem o bash (com .bash_profile), mas não consigo configurar as chamadas remotas. Esse é o problema. Estou procurando um arquivo que é originado por comandos bash e remoto.

Por exemplo:

O comando git-upload-pack localiza o arquivo exe, porque a variável env GIT_EXEC_PATH está definida, mas com remote: "git clone user@domain.com: myrepo local / myrepo" o servidor não encontra esse comando, porque o GIT_EXEC_PATH não está definido.

Edit2:

De acordo com isso , e meus registros printenv: o ~ / .ssh / rc está sendo executado no shell normal, não no subshell, por isso é um enigma porque as variáveis ​​env não estão aderindo ...

Eu criei um executável: ~ / logenv :

echo "" >> mylog.txt
date >> mylog.txt
printenv >> mylog.txt
echo "" >> mylog.txt

E coloque isso no ~ / .ssh / rc :

export AAA=teszt
source ~/logenv

Por login do bash e "logenv de origem", o resultado foi:

Tue May 15 04:21:37 MST 2012
TERM=cygwin
SHELL=/bin/bash
SSH_CLIENT=censored
SSH_TTY=/dev/pts/2
USER=myuser
AAA=teszt
MAIL=/var/mail/myuser
PATH=/usr/local/bin:/bin:/usr/bin
PWD=/home/content/65/7962465
SHLVL=3
HOME=/var/chroot/home/content/65/7962465
LOGNAME=myuser
SSH_CONNECTION=censored
_=/usr/bin/printenv

Tue May 15 04:21:41 MST 2012
HOSTNAME=censored
TERM=cygwin
SHELL=/bin/bash
HISTSIZE=1000
SSH_CLIENT=censored

Por remoto "ssh myuser@domain.com 'exec ~ / logenv'", o resultado foi:

Tue May 15 04:25:52 MST 2012
SHELL=/bin/bash
SSH_CLIENT=censored
USER=myuser
AAA=teszt
MAIL=/var/mail/myuser
PATH=/usr/local/bin:/bin:/usr/bin
PWD=/home/content/65/7962465
SHLVL=3
HOME=/var/chroot/home/content/65/7962465
LOGNAME=myuser
SSH_CONNECTION=censored
_=/usr/bin/printenv

Tue May 15 04:25:52 MST 2012
SHELL=/bin/bash
SSH_CLIENT=censored
USER=myuser
PATH=/usr/local/bin:/bin:/usr/bin
MAIL=/var/mail/myuser
PWD=/home/content/65/7962465
HOME=/var/chroot/home/content/65/7962465

Portanto, o arquivo rc é originado, mas depois disso as variáveis ​​desaparecem ...: S


Algumas opções neste segmento - stackoverflow.com/questions/216202/…
EightBitTony

"Ao contrário do / etc / sshrc, que é sempre processado pelo shell Bourne (/ bin / sh), seu arquivo rc é processado pelo shell de login normal da sua conta." - Isso é estranho, porque parece que ele não iria fontes de shell normal: S
inf3rno

Respostas:


12

Supondo que você tenha UsePAM yesparticipado /etc/ssh/sshd_confige assumindo que deseja que essas variáveis ​​de ambiente sejam definidas para todos os usuários, você pode ter variáveis ​​de ambiente definidas por eles. Se você tiver as variáveis ​​de ambiente definidas, /etc/gitenvpoderá adicionar esta linha ao/etc/pam.d/sshd

auth required pam_env.so envfile=/etc/gitenv

Ou ao inserir este arquivo, você pode achar que já existe um pam_env.so sendo usado e já existe um arquivo no qual você pode adicionar itens. Apenas tome cuidado e certifique-se de ter testado minuciosamente suas alterações antes de encerrar sua sessão ssh, pois quando estiver mexendo com o pam, você poderá interromper completamente sua capacidade de fazer login no servidor, se não tiver cuidado.


Eu tenho uma conta de host compartilhado, para poder modificar apenas o diretório ~. (Ele tem centos sistema op.)
inf3rno

@ inf3rno não faz mal ao votar com uma boa resposta :) pois de qualquer maneira a solução que resolverá o seu problema pode ser marcada por um meio diferente.
Huygens

Está bem. Eu vou, mas eu não sou o único que pode votar ... :-)
inf3rno

No Ubuntu, parece que /etc/environmenté originado por pam_env.sopor padrão
rcoup

4

Estou definindo alguma variável de ambiente para minhas conexões SSH usando o ~/.ssh/environment. O arquivo pode conter variáveis ​​no formulário VAR=value, sem necessidade de exportá-las explicitamente.

No entanto, esse arquivo de configuração do usuário é ignorado por padrão pelo processo do servidor SSH, a menos que a opção PermitUserEnvironment esteja configurada como yes. Portanto, você precisa editar / etc / sshd_config no servidor SSH para adicionar ou atualizar este parâmetro:

PermitUserEnvironment yes

Você precisa recarregar a configuração do servidor SSH. No RHEL ou Suse Linux, você faz (como root)

/sbin/service sshd reload

(Possivelmente substitua sshd por ssh se não funcionar)

No Ubuntu (usando o iniciante), você faz

sudo reload ssh

Em qualquer outro Linux, você pode tentar (como root)

/etc/init.d/sshd reload

(Substitua sshd por ssh ou openssh ou o que corresponder ao script de inicialização do servidor SSH)


Obrigado, mas não posso escrever no diretório / etc, o ambiente ~ / .ssh / não é originado.
Inf3rno

2

Eu não tenho mais um host compartilhado, então não posso verificar se as soluções propostas são válidas. Esta será a resposta aceita, pois funcionou por mim quando fiz a pergunta. As outras respostas podem funcionar também. Eu deixei a comunidade decidir isso com votos positivos.

Está bem. A solução é que não há solução em um host compartilhado como um godaddy. Eu tentei de tudo, mas nada funciona, então decidi ficar com as ~ / .ssh / allowed_keys:

command="~/connect.sh" ssh-rsa AAAAB3NzaC...

No ~ / connect.sh:

#!/bin/bash
if [ -f "${HOME}/.env_profile" ]; then
        source ~/.env_profile
fi;

if [ "x${SSH_ORIGINAL_COMMAND}x" == "xx" ]; then
        $SHELL --login
else
        eval "${SSH_ORIGINAL_COMMAND}"
fi;

E no ~ / .env_profile:

export PATH=$PATH:$HOME/bin:$HOME/git/libexec/git-core
export LD_LIBRARY_PATH=$HOME/git/lib
export GIT_EXEC_PATH=~/git/libexec/git-core
export GIT_TEMPLATE_DIR=~/git/share/git-core/templates

Então eu tenho que copiar o comando = "..." para cada chave rsa nas chaves_autorizadas. Isso é duplicação de código, mas não acho que exista outra solução em hosts compartilhados de maneira adequada.


1

Se você estiver usando bashcomo seu shell, tente adicionar as configurações de ambiente .bashrc.

Verifique primeiro se isso é executado no login, pois pode não ter, pois os arquivos padrão geralmente têm algo como:

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

no início deles. qualquer alteração que você queira fazer, mesmo para logons não interativos, precisará ir além dessa declaração.

.profileé um lugar mais geral para colocar configurações como esta e é respeitado pela maioria dos shells (em uma configuração padrão do Debian é o ~/.profileque chama ~/.bashrcem primeiro lugar). Pode ser necessário ter uma edição mais cuidadosa .profile, caso seja interpretada por outros shells - ou seja, tente evitar o uso de bashextensões específicas.

Editar

Se você tiver uma .bash_profileedição que, em vez de .profile: bash, a usará em favor do arquivo mais geral, e você poderá usar com segurança itens específicos do bash.


Leia a seção "Editar" pls. (.profile não está funcionando)
inf3rno

1

Você pode usar o comando para todos os usuários / chave sem adicionar a parte do comando nas allowed_keys, adicionando esta linha ao arquivo sshd_config:

ForceCommand ~/connect.sh

Nesse caso, sugiro que você use um caminho absoluto para o script


0

Estou propondo outra abordagem.

Você configura um arquivo com a declaração da sua variável de ambiente e o origina cada vez que chama um comando remoto.

Exemplo: você coloca as variáveis ​​necessárias em ~ / .my_var.rc e, em seguida, para cada comando remoto que executa ssh user@remote bash -c "source ~/.my_var.rc; <your command>"

Se isso lhe convier, você poderá refinar esse conceito e criar um script por conveniência. Se você precisar apenas para comandos git, eu criaria um script git.sh que faria isso:

#!/bin/bash

source ~/.my_var.rc

git $@

Supondo que esse script esteja no seu diretório pessoal, você poderia chamá-lo: ssh user@remote git.sh pull origin master

Nota: é um ponto de partida simples. Por exemplo, ele não suporta parâmetros com espaços.


Eu posso fazer isso ofc, mas que de configuração não é só para mim, e ele deve funcionar com gui git onde os comandos são gerados automaticamente ...
inf3rno

Você se conecta ao ssh remote usando o mesmo usuário? Se sim, o arquivo ~ / .my_var.rc seria específico do usuário e o git.sh comum a todos. Caso contrário, você poderá adicionar um parâmetro extra ao git.sh que ajudará a diferenciar qual arquivo .rc deve ser originado (ou usando IP fixo, você poderá usar as informações env SSH_CLIENT para diferenciar seus usuários). O comando deve trabalhar com gui git, chamadassh -Y user@remote git.sh gui
Huygens

Eu preciso das mesmas configurações de ambiente para cada usuário. Não vou acrescentar parte extra para os comandos, é um absurdo ...
inf3rno

Bem, se as configurações são as mesmas para todos os usuários, a resposta está completa e você pode desconsiderar meu comentário anterior. Você provavelmente precisaria colocar os arquivos .rc e .sh em um diretório comum a / acessível por todos os usuários.
Huygens 15/05

@ inf3rno se você quiser mais respostas, já deve agradecer aquelas que propuseram boas respostas, mesmo que não sejam aplicáveis ​​ao seu caso, porque faltam informações na pergunta original. Ou as pessoas não se incomodarão em tentar.
Huygens

0

Isso não responde à pergunta geral sobre PATHS, mas permite que você use um repositório git em um servidor remoto que não tenha git em seu caminho e ao qual você não tenha acesso root. Esta solução vem desta página .

git clone -u relative/path/to/bin/git-upload-pack username@host.com:relative/path/to/remote_repository.git

Para também empurrar e buscar:

git config remote.origin.receivepack relative/path/to/bin/git-receive-pack
git config remote.origin.uploadpack relative/path/to/bin/git-upload-pack

0

O / etc / profile será originado em cada conexão com o ssh-client.


Somente para shells de login.
RalfFriedl
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.