0

plink is Windows executable, which connects by ssh and does some command on server side.

For example

plink myname@mycomputer ls

will show result of ls command, being executed in the home directory of myname.

Unfortunately, neither ~/.profile nor ~/.bashrc is executed.

What is contract for ssh connection and what defines, which variables are set and which ones are not? If I run

plink myname@mycomputer env

I see some variables like HOME, PWD and LOGNAME which are specific to the user. How to set other ones?

Neither of the following helped:

plink myname@mycomputer sh -c env

plink myname@mycomputer bash -c env

These commands worked, but showed "naked" set of variables.

How to tell shell to execute it's initial scripts for the user?

2
  • 1
    Try: bash -ic env Commented Dec 12, 2017 at 15:39
  • ... might need -t as well to force allocation of a tty Commented Dec 12, 2017 at 16:05

1 Answer 1

1

What ssh runs can be observed with e.g. sysdig in one terminal and then elsewhere running plink myname@mycomputer uptime which should show something like

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

so in this case bash is being run (this may not be the case for example on Alpine Linux which does not install bash by default) with the -c uptime arguments. This causes bash to more or less directly exec that command as there's no fancy pipeline or multiple shell commands that necessitate that bash continue to run.

Next, we can log what files bash opens, and again run the plink ... uptime command (this may be more verbose depending on what else is going on on the system):

$ 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

So it appears /root/.bashrc here is being read on my test virt; to confirm this we can add something to that file and again run our test command, on the server:

echo echo echo >> ~/.bashrc

and then we connect again (adjust the command to be plink ... as necessary)

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

so in this case .bashrc is being read, so you could put commands in there. I am not sure why in your case .bashrc is not being read; trace things to see what is going on.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .