1

Edit: The hint for restarting ssh after editing /etc/ssh/sshd_config solved my issue (sudo systemctl restart ssh.service on Ubuntu) but see the accepted answer for a lot more of useful troubleshooting.

Original:

I have a server which I connect to via a jump host:

export MY_ENV=myvalue
ssh -o StrictHostKeyChecking=yes -o SendEnv=MY_ENV -J <myuser@jumpHostIp> <myuser@hostIp>

Both the jump host and the host have in their /etc/ssh/sshd_config:

AcceptEnv MY_ENV

Both the jump host and the host have in their /home/myuser/.ssh/authorized_keys the ssh key limiting myuser to a deploy script:

command=/home/myuser/deploy.sh ...rest of public key...

Inside this deploy.sh I would like to use $MY_ENV, however it does not work.

Is using a jump host somehow dropping the value of MY_ENV transfered by SendEnv? If yes is this intended or how can I access the value of MY_ENV in deploy.sh on the host?

Tom
  • 503
  • 2
  • 13

1 Answers1

1

Edit: I refined the details regarded during our iteration process, partly dubbing some details already named in the question for better general use.

The man page of ssh states:

Note that configuration directives supplied on the command-line generally apply to the destination host and not any specified jump hosts. Use ~/.ssh/config to specify configuration for jump hosts.

So your final destination will receive the options added by -o. As the options are not touched by the jump host, it is not necessary to configure the jump host for the variables to pass to the destination host.

Config of sshd at the destination server

As a prerequisite the destination-host's sshd service has to be configured to accept the environment variable. Wildcards are allowed:

File: /etc/ssh/sshd_config

AcceptEnv MY_*

After a change of the sshd_config the sshd has to be restarted to read the updated configuration.
(the solution for this question ...)

systemctl restart sshd

The current connection will persist, when restarting the sshd (at least when using "openssh-server"

Pitfall in authorized_keys

To limit the key-usage at the destination system, an option can be added to the authorization.

File: authorized_keys with limitation to a command

The whole PublicKey-Authentication will fail, when omitting the " quotations enclosing the value of the command option:

command=/home/user/deploy.sh ssh-rsa AAAAB3NzaC1yc2EAA...

# DEBUG response of sshd:
debug1: /home/user/.ssh/authorized_keys:1: bad key options: missing start quote

Depending on the settings in sshd_config a fallback to password based authentication, respectively a Permission denied (publickey). will follow.

The " quotations are required, even if there is no white space in the command:

command="/home/user/deploy.sh" ssh-rsa AAAAB3NzaC1yc2EAA...

Details for the client's command

Note: Besides the command-line options these details can be configured at the client user's ~/.ssh/config.

To pass the desired variable as option at the command-line two variants are possible as syntax:

-o SendEnv=MY_ENV
-o "SendEnv MY_ENV"

Please do not forget the " quotes.

Essential for the availbility of the variable is not only to set it, you have to export it:

This will fail:

MY_ENV="Value"
echo $MY_ENV
Value

... despite the fact that the variable shows up in the current shell.

Required:

export MY_ENV="Value"
dodrg
  • 1,142
  • 2
  • 18
  • The alternate syntax is not working. However I noticed that if I name my environment variable LC_MY_ENV its going through to the deploy.sh ( with -o SendEnv LC_MY_ENV)! So this means something is blocking the variable MY_ENV even though I added it to /etc/ssh/sshd_config "AcceptEnv MY_ENV" of both the jump host and host. Do you have an idea what it could be? – Tom Apr 01 '23 at 10:54
  • At my system the alternate syntax is accepted as well as yours. — Did you include the quotes when issuing the command? — They are not included in your comment, so I got suspicious about this. – dodrg Apr 01 '23 at 11:05
  • Yes I use "export" and I did use the quotes. Its not the parameter format. LC_MY_ENV is going through in both of the formats. Its somehow that everything starting with LC_* is passing through but just MY_ENV without the "LC_" is not. So there must be some other place other than /etc/ssh/sshd_config where I have to allow MY_ENV? – Tom Apr 01 '23 at 11:40
  • Hmm, it look like I've to get a test configuration. — Is it possible for you to test the command starting at the jumphost (so testing the final host without an intermediate jumphost)? — Reduced complexity to track down the problem would be useful. – dodrg Apr 01 '23 at 11:50
  • Alternatively: Do you know about the possibility to define variables at the destination host in `~/.ssh/environment` (at the destination host user home)? — It depends on your script concept how usefull this is. – dodrg Apr 01 '23 at 12:00
  • Defining variables at the destination host is not useful as my variable is set externally by the person deploying. It tells the deploy.sh which branch of our git repository to deploy. I did a test without the jump host (temporarily opening things) and MY_ENV reaches the deploy script! So its something on the jump host or it has to do with using a jump host. Thanks for the help so far btw! – Tom Apr 01 '23 at 12:15
  • You didn't mention yet: despite the problem with MY_ENV, the ssh connection via jumphost succeeds? – dodrg Apr 01 '23 at 12:19
  • Oh yes, the deploy.sh is executed also with a jump host. In there I have "echo $MY_ENV" and other test commands, thats how I know MY_ENV does not reach deploy.sh with a jump host. – Tom Apr 01 '23 at 14:12
  • I refined my answer, as I could verify the details by my setup of a jumphost path. — As an almost trivial (but common) fault: *Did you restart your sshd at the destination host after the reconfiguration with `AcceptEnv MY_ENV`*? – dodrg Apr 01 '23 at 15:17
  • Its working!! I did not know you had to restart it. Thanks for helping so much! I would like to accept your answer, can you stick a big fat "you have to restart sshd for changes to take effect" in front of your answer : )? – Tom Apr 03 '23 at 08:53
  • Answer updated. Nice to hear that the efforts have been successful. – dodrg Apr 03 '23 at 10:26