Web Development

OpenSSH login tricks

Vincent Danen is a fan of OpenSSH for remote connections. Here, he shares some tricks for streamlining remote access to systems using SSH.

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
  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.

Delivered each Tuesday, TechRepublic's free Linux NetNote provides tips, articles, and other resources to help you hone your Linux skills. Automatically sign up today!


Vincent Danen works on the Red Hat Security Response Team and lives in Canada. He has been writing about and developing on Linux for over 10 years and is a veteran Mac user.


To limit the ability of users to use su so that only admins, with a previously registered public / private key pair can use su: Compile sshd with the match keyword patch (http://bugzilla.mindrot.org/show_bug.cgi?id=1180), and use it to ensure that members of the admin group can only log in using public/private key authentication. Also make these users a member of the wheel group, and ensure that only they can su - check out /etc/pam.d/su. For example, in /etc/ssh/sshd_config add: Match Group admins PubkeyAuthentication yes PasswordAuthentication no ChallengeResponseAuthentication no In /etc/pam.d/su ensure the following is uncommented: # Uncomment the following line to require a user to be in the "wheel" group. auth required /lib/security/$ISA/pam_wheel.so use_uid I use this method to ensure that admins can only log in using public/private keys and have access to perform admin functions while (hopefully) ensuring that "normal" users cannot mess about. This also has the advantage that if any user uploads their own keys to ~/.ssh that they will not be able to gain admin rights!!! This does not limit the ability of non admin users from doing their work, only stops them from using root access to alter the system. If ssh is exposed to the internet, this is a means of securing it further against crack attempts, protecting the system from exploitation. edited for typo


Thanks for that article. I appreciate learning more about the basic tools I use in Linux. Especially shortcuts.


Indeed, quite a cool trick the one that you provided. If any use, I'd like to suggest PuTTY and pagent, a great SSH client and key agent (avoid retyping passwords all the time) so that you can connect from Windows to any SSH server around. And for SCP operations, we use WinSCP. Also, I post tips and tricks on my site www.somethingforit.com, maybe paying a visit would be worth the while. Thanks for the idea!

barry stear
barry stear

Thanks for the url to your site. I just popped over there to look and I am sure I will be using your site for many tips and tricks thanks. Might even hit you up for help. I am still fairly new to Linux so be prepared..

Editor's Picks