Como definir variáveis de ambiente para plink.exe?

0

plink é o executável do Windows, que se conecta por ssh e faz algumas comando no lado do servidor.

Por exemplo

plink myname@mycomputer ls

mostrará o resultado do comando ls, sendo executado no diretório home do myname.

Infelizmente, nem ~/.profile nem ~/.bashrc é executado.

O que é contrato para ssh connection e o que define, quais variáveis são definidas e quais não são? Se eu correr

plink myname@mycomputer env

Eu vejo algumas variáveis como HOME , PWD e LOGNAME que são específicas para o usuário. Como definir outros?

Nenhum dos seguintes ajudou:

plink myname@mycomputer sh -c env

plink myname@mycomputer bash -c env

Estes comandos funcionaram, mas mostraram um conjunto "nu" de variáveis.

Como dizer ao shell para executar seus scripts iniciais para o usuário?

    
por Dims 12.12.2017 / 16:19

1 resposta

1

Quais ssh corridas podem ser observadas com, e. sysdig em um terminal e depois em outro local executando plink myname@mycomputer uptime , que deve mostrar algo como

$ sudo sysdig -p '%proc.cmdline' 'evt.type = execve'
sshd
bash -c uptime
bash -c uptime
uptime

então, neste caso, bash está sendo executado (isso pode não ser o caso, por exemplo, do Alpine Linux, que não instala bash por padrão) com os argumentos -c uptime . Isso faz com que bash seja mais ou menos diretamente exec do comando, já que não há nenhum pipeline sofisticado ou vários comandos de shell que exigem que bash continue sendo executado.

Em seguida, podemos registrar quais arquivos bash são abertos e executar novamente o comando plink ... uptime (isso pode ser mais detalhado dependendo do que está acontecendo no sistema):

$ sysdig 'evt.type = open and proc.name = "bash"'
7847 16:03:48.388447919 0 bash (22135) > open
7848 16:03:48.388466237 0 bash (22135) < open fd=3(<f>/etc/ld.so.cache) name=/etc/ld.so.cache flags=4097(O_RDONLY|O_CLOEXEC) mode=0
7855 16:03:48.388669720 0 bash (22135) > open
7856 16:03:48.388695391 0 bash (22135) < open fd=3(<f>/lib64/libtinfo.so.5) name=/lib64/libtinfo.so.5 flags=4097(O_RDONLY|O_CLOEXEC) mode=0
7871 16:03:48.389069345 0 bash (22135) > open
7872 16:03:48.389082901 0 bash (22135) < open fd=3(<f>/lib64/libdl.so.2) name=/lib64/libdl.so.2 flags=4097(O_RDONLY|O_CLOEXEC) mode=0
7885 16:03:48.389284722 0 bash (22135) > open
7886 16:03:48.389290872 0 bash (22135) < open fd=3(<f>/lib64/libc.so.6) name=/lib64/libc.so.6 flags=4097(O_RDONLY|O_CLOEXEC) mode=0
7921 16:03:48.391876315 0 bash (22135) > open
7922 16:03:48.391927051 0 bash (22135) < open fd=-6(ENXIO) name=/dev/tty flags=67(O_NONBLOCK|O_RDWR) mode=0
7945 16:03:48.393905761 0 bash (22135) > open
7946 16:03:48.393957884 0 bash (22135) < open fd=3(<f>/proc/meminfo) name=/proc/
meminfo flags=4097(O_RDONLY|O_CLOEXEC) mode=0
8049 16:03:48.395910893 0 bash (22135) > open
8050 16:03:48.395916693 0 bash (22135) < open fd=3(<f>/root/.bashrc) name=/root/.bashrc flags=1(O_RDONLY) mode=0

Então parece /root/.bashrc aqui está sendo lido no meu teste virt; para confirmar isso, podemos adicionar algo a esse arquivo e executar novamente nosso comando de teste, no servidor:

echo echo echo >> ~/.bashrc

e depois nos conectamos novamente (ajuste o comando para ser plink ... conforme necessário)

$ ssh gato uptime
echo
 16:05:20 up  5:19,  1 user,  load average: 0.11, 0.38, 0.27
$ 

então, neste caso, .bashrc é sendo lido, então você pode colocar comandos lá. Não sei porque no seu caso .bashrc não está sendo lido; rastreie as coisas para ver o que está acontecendo.

    
por 12.12.2017 / 17:16