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 guard.example.com
[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 guard.example.com
Hostname guard.example.com
ForwardAgent yes
ForwardX11 no
LocalForward 9001 10.0.2.50:22
LocalForward 9002 10.0.2.51:22
LocalForward 9003 10.0.2.52:22
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.