Connecting seamlessly with ssh through intermediate hosts

Having machines in a network that is only reachable through an intermediate machine (e.g. a firewall) can make using ssh less comfortable. When using VPN or changing the network layout is not an option - the ssh ProxyCommand option can help. The result is being able to connect to hosts with one command through the intermediate machine. This also enables using rsync or versioning systems over ssh which otherwise wouldn’t work directly.

The intermediate machine is named “intermediate” and the target machine (which is in the not directly reachable network) “target”. The ~/.ssh/config entries should look like this:

Host intermediate
   Hostname 192.168.1.1
....
Host target
    ProxyCommand ssh -e none intermediate exec nc -w 1000 %h %p
....

So when you execute:

$ ssh target

An ssh connection to “intermediate” is opened. netcat is started on “intermediate” to forward the ssh session to “target”. nc -w sets a connection timeout, this should make sure that “intermediate” doesn’t run abandoned nc processes. ssh -e none disables escape chars, they are not useful in this case and can only cause problems.

Personalizing shell accounts that are used by multiple users

Problem description

Although it is generally discouraged to share a shell account with multiple users, sometimes its necessary. When I recently had to share a login I wanted to recreate my personalized environment, but then again not mess with other peoples environment. Also I wanted to preferably create something they could use for themselves without messing in turn my environment up (for example by configuring emacs as the default text editor). I wanted to have my own .bash_history file, load my own .vimrc etc. I used Debian 6.0 with current ssh/sshd versions.

Overview

What I did was exporting an LC_* environment variable on the client machine; those get forwarded by the ssh client to the server. On the server I would check in the .bashrc file whether the variable was set, if it was set I would load the custom configuration files. Any of the users who share the account are then able to configure the server environment for themselves.

Implementation

I added this line to ~/.bashrc

.....
export LC_USER=michael
.....


Don't forget to source the .bashrc file after it was edited, otherwise it will have no effect in the active session, this can be done with

$ source ~/.bashrc


You should have SendEnv set to forward the LC_* variables (this is usually enabled). This can be done in either the global ssh config /etc/ssh/ssh_config or the user ssh config: ~/.ssh/config

....
SendEnv LANG LC_*
....


On the server where you want to connect to, the file /etc/ssh/sshd_config should have the following option enabled (this is often enabled by default)

....
AcceptEnv LANG LC_*
....


To verify, ssh into the target machine and try this, the result should be similar. If you get no response check whether the variable was even exported locally (use the same command).

$ env | grep LC_
LC_USER=michael


Once this is done, upload your personalized .bashrc file to the remote server into ~/.yourusername/.bashrc .

Finally edit the ~/.bashrc file on the server so it sources the new custom file:


if [ `expr match "$LC_USER" '^[a-zA-Z0-9]\+$'` -gt 0 ] ;
then
echo "Welcome ${LC_USER}"
source ~/.${LC_USER}/.bashrc
fi


To keep a personal .bash_history and .vimrc file, put the following into the personal .bashrc file (don't forget to upload your .vimrc file into ~/.${LC_USER}).

HISTFILE=./.bash_history
alias vim='vim -u ~/.${LC_USER}/.vimrc'


Conclusion

This proved to be a noninvasive and reliable way to share accounts with custom configurations. Other ways to solve this problem might have been the usage of IP addresses. I looked into this first, but then decided that its not very good since connecting through intermediate machines would render discrimination of users impossible.