SSH - conjunto de env vairables por cada conexão - godaddy shared host

9

Meu problema é que eu tenho que definir variáveis env (como GIT_EXEC_PATH) em um servidor. Eu preciso que as variáveis por cada conexão (assim por bash e por comandos remotos também). Eu consegui definir essas variáveis por bash com .bash_profile, mas tenho problemas com os comandos remotos. Eu descobri que é possível escrever comandos em ~ / .ssh / authorized_keys antes da chave rsa atual, mas eu não quero escrever lá sempre, eu preciso de uma solução permanente ... Eu achei que o ~ / .ssh / rc arquivo é executado por cada login ssh, então eu coloquei lá minhas declarações de variáveis env, mas não funcionou. As variáveis são definidas no arquivo rc, mas depois disso elas 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 a duplicação de código?

Editar:

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

  1. O ~ / .bash_profile é originado (somente por conexões bash),
  2. o ~ / .bashrc nunca é originado,
  3. o ~ / .profile nunca é originado,
  4. o ambiente ~ / .ssh / nunca é originado,
  5. o ~ / .ssh / rc é originado (por bash e remoto ambos), mas eu acho que é chamado em subshell, porque as variáveis desaparecem.
  6. O ~ / .ssh / authorized_keys é originado por todas as vezes, mas eu tenho que escrever os comandos antes de cada chave rsa (então eu não quero configurar com isso).

Resumo:

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

Por exemplo:

O comando git-upload-pack localiza o arquivo exe, porque a variável env do GIT_EXEC_PATH está definida, mas com o remote: "git clone [email protected]: meurepo local / meurepo" o servidor não encontra esse comando, porque o GIT_EXEC_PATH não está definido.

Edit2:

De acordo com este e meus registros printenv: o ~ / .ssh / rc está rodando no shell normal, não no subshell, então é um enigma por que as variáveis do env não grudam ...

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 bash login & "source logenv" 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 [email protected] '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

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

    
por inf3rno 14.05.2012 / 12:22

7 respostas

1

Não tenho mais um host compartilhado godaddy, por isso não posso verificar se as soluções propostas são válidas. Essa será a resposta aceita, pois funcionou comigo quando fiz a pergunta. As outras respostas podem funcionar também. Eu deixo a comunidade decidir isso com upvotes.

Ok. A solução é que não há solução em um host compartilhado godaddy. Eu tentei de tudo, mas nada funciona, então eu decidi ficar com o ~ / .ssh / authorized_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 authorized_keys. Isso é duplicação de código, mas não acho que haja outra solução em hosts compartilhados do godaddy.

    
por 16.05.2012 / 23:08
6

Supondo que você tenha UsePAM yes em /etc/ssh/sshd_config , e supondo que você deseja que essas variáveis de ambiente sejam definidas para cada usuário, você pode ter variáveis de ambiente pam set para você. Se você tiver as variáveis de ambiente definidas em /etc/gitenv , você pode adicionar essa linha a /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á um arquivo para o qual você pode adicionar coisas. Apenas tome cuidado, e certifique-se de ter testado suas alterações antes de finalizar sua sessão ssh, como quando você está mexendo com o pam, você pode quebrar completamente a sua capacidade de acessar seu servidor, se você não for cuidadoso.

    
por 14.05.2012 / 12:50
2

Estou configurando uma variável de ambiente para minhas conexões SSH usando o ~/.ssh/environment . O arquivo pode conter variáveis no formato VAR=value , não é necessário 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 certificar-se de 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 upstart) 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 for que corresponda ao script de inicialização do servidor SSH)

    
por 14.05.2012 / 13:30
1

Se você estiver usando bash como seu shell, tente adicionar as configurações do ambiente a .bashrc .

Primeiro, verifique se isso é executado no login, pois os arquivos padrão geralmente têm algo como:

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

no começo deles. qualquer mudança que você queira ter, mesmo para logins não interativos, precisará estar acima de tal declaração.

.profile é um local mais geral para colocar configuração como essa e é respeitado pela maioria das shells (em uma configuração padrão da Debian é ~/.profile que chama ~/.bashrc em primeiro lugar). Talvez seja necessário ter mais cuidado ao editar .profile caso alguma vez seja interpretada por outros shells, ou seja, tente evitar o uso de% de extensões específicas debash.

Editar

Se você tem um .bash_profile edit que em vez de .profile : bash irá usá-lo em favor do arquivo mais geral, e você pode usar com segurança coisas específicas do bash nele.

    
por 14.05.2012 / 13:37
1

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

ForceCommand ~/connect.sh

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

    
por 03.06.2014 / 13:32
0

Estou propondo outra abordagem para você.

Você configura um arquivo com a declaração de sua variável de ambiente e, em seguida, o nomeia cada vez que você chama um comando remoto.

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

Se isso combina com você, você pode refinar esse conceito e roteirá-lo por conveniência. Se você precisar apenas de comandos git, eu criaria um script git.sh que faria isso:

#!/bin/bash

source ~/.my_var.rc

git $@

Supondo que este script estaria em seu diretório home, você o chamaria: ssh user@remote git.sh pull origin master

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

    
por 15.05.2012 / 09:44
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 para o qual você não tenha acesso root. Esta solução vem de esta página .

git clone -u relative/path/to/bin/git-upload-pack [email protected]:relative/path/to/remote_repository.git

Para também enviar 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
    
por 15.11.2016 / 08:30