3

On the local server, I have a program that stores the password in the predefined environment variable (SPECIAL_PASSWORD).

On the remote server I have a program that reads and uses a password from a predefined environment variable (SPECIAL_PASSWORD).

I want to execute the program on the remote server and supply the password already set in my local environment.

My attempt looks as follows:

local_command # produces the SPECIAL_PASSWORD Env Var
ssh -l remote_user remote_server <<EOSSH
export SPECIAL_PASSWORD=${SPECIAL_PASSWORD} # Transfer Env Var
remote_command # consumes SPECIAL_PASSWORD Env Var
EOSSH

It also seems to work as intended:

  1. Unix ps does not seem to reveal the password
  2. access to the password is only available to the current processes or their child processes.

But is it truly safe to do so ... is at any point the password readable? Is there a better alternative?

I could potentially change the sshd_config (AcceptEnv) and ssh_config (SendEnv) to allow to transmit a subset of environment variables without above trick. However the systems are tightly controlled, and sshd_config requires admin intervention. In my case, it doesn't seem a possibility to change the sshd_config.

UPDATE

I am using a different solution offered by piping data into the remote ssh command be ran. Note that this syntax does not work anymore in combination with HERE documents.

sendEnv() {
  echo "var1=${var1}"
  echo "var2=${var2}"
  ...
}

sendEnv | ssh -l remote_user remote_server "receiving_command".

In my case the receiving_command is a java program that reads the environment variables from System.in.

It works like a charm.

3

It's readable by remote_user and root. None other, unless remote_command is writing it to a globally readable file or something like that.

You can inspect the environment of a process in the /proc filesystem in /proc/$pid/environ. You either need to be the same user as the euid of $pid or you need to be root, as the permissions of that file seem to default to -r-- --- ---.

Apart from using the environment, you could also pass the password via stdin by piping into ssh. If you pipe into ssh, only root and the target program (and it's children) will be able to get to it as far as I know (assuming $(cat /proc/sys/kernel/yama/ptrace_scope) == 1 ).

  • Thanks - that is real good input, I did not know about /proc/$pid/environ. I am for now leaving unanswered waiting for someone to find other holes. I am not sure at this point if access by remote_user is acceptable or not, need to think real hard about that. – YoYo May 29 '15 at 1:09
  • 1
    If you pipe into ssh, only root will be able to get to it as far as I know (assuming $(cat /proc/sys/kernel/yama/ptrace_scope) == 1 )), apart from the target program, of course. – PSkocik May 29 '15 at 1:21
  • Ok - real good idea - can you update this as part of your answer? – YoYo May 29 '15 at 1:32
  • 1
    As the keystore exposes the environment variables to the user through the environment variables, it does not matter that the same user can also access through /proc/$pid/environ. Only additionally, it also gets exposed to the target system's user. However, I am ok, the users are sufficiently protected, and I do not leave readable files behind. On the other hand your solution with piping the data also really appeals for me, and I might use it to transmit bigger datasets. – YoYo May 29 '15 at 19:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.