Use the $USER
environment to set a user
Host MYHOST
Hostname MYHOST
User $USER
Check this for more SSH Environment Variables
SSH Environment Variables
Passing env variables to a ssh connection
SSH - set env vairables by every connection
When ssh'ing, how can I set an environment variable on the server that changes from session to session?
Other reasons environment variables are not being interpreted on the client side:
- is the environment variable
set correctly
- is the environment variable
exported
- Check the
ssh_config
for SendEnv
, is your environment variable listed
SendEnv ENV_VARIABLE
- Try using the -t option
ssh -t ...
- Create a
~/.ssh/environment
file on the client
ENV_VARIABLE=VALUE
Set PermitUserEnvironment
to yes on the server in sshd_config
file
If you are trying to use user environment variables in an SSH session and they are not being interpreted,maybe that your ssh client is not configured to pass your environment variables.
To pass environment variables, you can use the -t option when you connect to the host. This option tells SSH to allocate a pseudo-tty on the remote host, which allows environment variables to be passed
You may need to check your SSH client configuration or the documentation of your client
or
Use the SendEnv
and AcceptEnv
directives
Add this to you /etc/ssh/sshd_config
AcceptEnv SSH_USER
sshd_config(5) — Linux manual page | AcceptEnv
or
Use the $SSH_USER
environment to set a use, maybe this will not work on all systems
Host MYHOST
Hostname MYHOST
User $SSH_USER
When you run the ssh command, it will read the value of the SSH_USER environment variable to replace the $SSH_USER
You will need to set the SSH_USER environment variable every time you open a new terminal session or add it to your ~/.bashrc
to make it persist.
Search in the Bash CookBook for $SSH_USER
, there are a view chapters, I only mentioned one:
Check this chapters:
10.3 Using Configuration Files in a Script
15.11 Getting Input from Another Machine
Bash CookBook
10.3 Using Configuration Files in a Script
Problem
You want to use one or more external configuration files for one or more scripts.
Solution
You could write a lot of code to parse some special configuration file format. Do
yourself a favor and don’t do that. Just make the config file a shell script and use the
solution in Recipe 10.2.
Discussion
This is just a specific application of sourcing a file. However, it’s worth noting that
you may need to give a little thought to how you can reduce all of your configuration
needs to bash-legal syntax. In particular, you can make use of Boolean flags and
optional variables (see Chapter 5 and Recipe 15.11):
# In config file
VERBOSE=0 # 0 or '' for off, 1 for on
SSH_USER='jbagadonutz@' # Note trailing @, set to '' to use the current user
# In script
[ "$VERBOSE" ] || echo "Verbose msg from $0 goes to STDERR" >&2
[...]
ssh $SSH_USER$REMOTE_HOST [...]
Of course, depending on the user to get the configuration file correct can be chancy,
so instead of requiring the user to read the comment and add the trailing @, we could
do it in the script:
# If $SSH_USER is set and doesn't have a trailing @ add it:
[ -n "$SSH_USER" -a "$SSH_USER" = "${SSH_USER%@}" ] && SSH_USER="$SSH_USER@"
or just use:
ssh ${SSH_USER:+${SSH_USER}@}${REMOTE_HOST} [...]
to make that same substitution right in place. The bash variable operator :+ will do
the following: if $SSH_USER has a value, it will return the value to the right of the :+
(in this case we specified the variable itself along with an extra @); otherwise, if unset
or empty, it will return nothing.
See Also
• Chapter 5
• Recipe 10.2, “Reusing Code with Includes and Sourcing”
• Recipe 15.11, “Getting Input from Another Machine”
Discussion
We do a few interesting things here. First, notice how both $SSH_USER and $SSH_ID
work. They have an effect when they have a value, but when they are empty they
interpolate to the empty set and are ignored. This allows us to abstract the values in
the code, which lends itself to putting those values in a configuration file, putting the
code into a function, or both.