OpenSSH login tricks

By Team Digit Published Date
20 - Feb - 2007
| Last Updated
20 - Feb - 2007
OpenSSH login tricks

OpenSSH is a fantastic tool with a great variety of options and tricks available if you're creative enough to figure them all out. For remote connections and administration, there is no more flexible and powerful tool than OpenSSH.

For instance, assume that you have access to a variety of machines on a remote network, but can only get to those systems through a bastion host. Suppose that the "gateway" to the remote network is on a machine (called guard), which allows ssh connections. From that system, you are then able to ssh into other systems. However, to obtain any access to the other systems, you must always go through guard.

A typical login scenario, then, might look like:

[me@myhost]$ ssh
[me@guard]$ ssh work1

If you connect to those other systems (such as work1) often, it can become tiresome to always connect to guard and then connect to the other system. OpenSSH allows us a few tricks to get around this, so you can simply do ssh work1 on your home system and log in to the remote work1 system without first logging into guard.

Edit your ~/.ssh/config file. Here you'll add a few lines to get the configuration correct.

Host guard
  ForwardAgent yes
  ForwardX11 no
 LocalForward 9001
  LocalForward 9002
  LocalForward 9003
Host w1 w2 w3
  ForwardAgent yes
  ForwardX11 no
  Hostname localhost
  NoHostAuthenticationForLocalhost yes
Host w1
  Port 9001
Host w2
  Port 9002
Host w3
  Port 9003

Essentially, what you are doing is setting a few Host configurations to allow you to easily connect to the remote work systems, which you will nickname "w1", "w2", and "w3" (it doesn't really matter what the remote system's name is since you're connecting via the IP address as noted in the LocalForward statements). This is all fairly self-explanatory with the exception of the "NoHostAuthenticationForLocalhost" keyword. This will prevent ssh from complaining each time you connect to one of the remote systems; because each connection is through the localhost, yet to a different physical machine, ssh will note that the host keys for "localhost" keep changing and complain (loudly) without this option.

Now you need to fire up your "master connection", which will be the control channel that all connections to the remote systems will travel through. This connection is the one that will authenticate to guard and remain open:

$ ssh -fMN guard

This will open the master connection in the background and now you can connect to those remote systems easily using "ssh w1" or "ssh w2". This also allows you to easily scp files from the local system to a remote system without copying the files twice: first to guard and from there to the remote system.

Team DigitTeam Digit

All of us are better than one of us.