By default the only environment variable that's transmitted over an SSH connection is TERM
. You can pack information there but you've got to be sure that it'll be unpacked on the server side. The client can transmit other messages, but the server needs to be set up to accept them with an AcceptEnv
directive in /etc/sshd_config
. Under Debian and most derivatives (Ubuntu, Mint, …) all variables whose name begins with LC_
are also accepted by the SSH server. These variables are conventionally used for locale settings, but you can use one of your own to pass something else. If your server allows it, you can simply write
LC_STARTUP_OPTION=A ssh
Another possibility is to run a command based on the user authentication key (this requires only control of ~/.ssh/authorized_keys
, not the sshd configuration).
If you aren't able to transmit environment variables, you can set it on the command line and then execute an interactive shell, as you've been doing. Since you're executing a new shell (that's necessary because you can't both specify an initial command to run and get an interactive shell), this needs to be an environment variable, not a shell variable.
ssh -t machine@domain 'export STARTUP_OPTION="A"; exec /path/to/zsh'
Yet another approach is to feed some data to the shell via its standard input, and then redirect the standard input to the terminal.
ssh -t localhost 'echo "echo foo; exec </dev/tty" | exec zsh -i'
stdin: is not a tty
stty: standard input: Inappropriate ioctl for device
~%
Despite the error messages about not being able to initialize the terminal, zsh seems to cope properly with the interactive part of the session.