Connecting to Farm and QCD Interactive Nodes

This page is a preview of the above content, for the full web page follow the link above.

 

Login Nodes

In order to meet updated security requirements, the interactive nodes (ifarm/qcdi) now sit behind 2-factor login nodes.  The login nodes can be reached from on- and off-site.  This model is similar to existing workflows used by acclogin.jlab.org and hallgw.jlab.org.  Current login nodes are

  • scilogin.jlab.org.,
  • acclogin.jlab.org., and
  • hallgw.jlab.org..

NOTE:  direct connections to ifarm/qcdi nodes are expected to be BLOCKED from all user VLANs.  Connections must be made directly from a 2-factor login node.  Actions like ssh hallgw => mydesktop => ifarm will NOT be allowed, as opposed to

  • ssh hallgw => ifarm (ALLOWED) and
  • ssh hallgw => mydesktop => scilogin => ifarm (ALLOWED).

See article on configuring ProxyJump in your .ssh/config to streamline this workflow.

QCD Users:  references to ifarm/Farm within the article should be treated as examples.  Substitute your specific qcdi hostname as appropriate.

 

Prerequisites

  1. Multi-Factor Authentication (MFA), one of
  2. account access, one of

 

Connecting to JLab Interactive Nodes

Please ensure all prerequisites in the list above have been met.  Then, to access the Farm using SSH you can

Alternatively, one can use the ProxyJump directive (-J).  Just remember the first login is 2-factor and the second is CUE password, and that mistyped credentials can result in additional, confusingly-unlabled password prompts, depending on your OpenSSH version.

See below if your version of OpenSSH does not support -J.  The second authentication can also be via SSH key instead of CUE password, to your personal account or group account, but the first authentication must be two-factor and using your personal account.

X-forwarding

To run an X client application, you may need to specify the appropriate flag (if X-forwarding isn't configured in the SSH system or user client configuration). 

An easy test to make sure it's working is to try running xclock

If it's working, you will see the xclock graphical clock open on your local display. If not, retry swapping -X with the -Y flag.  See below if your version of OpenSSH does not support -J.

Transferring Files

Files can be transferred with scpsftp, or rsync. For simplicity, we'll show scp using ProxyJump (-J):

Use -r to copy whole directories. Note that if you try to scpsftprsync, or otherwise transfer files to and from scilogin directly, you will not have access to the same filesystems that are available on ifarm or qcdi.  See below if your version of OpenSSH does not support -J.

ProxyJump Configuration (Advanced)

Instead of using -J in the above commands or figuring out the ssh options to pass rsync, refer to our article on configuring ProxyJump. It tries to include many possible cases, but should be fairly easy to copy/paste.

After that, your individual commands will be greatly simplified. 

Issues

Generally

To simplify things, you can bypass your .ssh/config.  If the following works, the problem is likely with your config file.

which if works means specifically that the problem with your config file is that OpenSSH is ignoring it, and if does not work will give a much more obvious error if, for example, you created the config file in the wrong location and ~/.ssh/config therefore does not exist.

If your OpenSSH doesn't support -W, that suggests it is a version older than 5.4, and, while there exist solutions involving the use of programs like netcat, versions of OpenSSH older than 5.4 were last shipped in Enterprise Linux 6 and Ubuntu 10.04 "Lucid," which reached end-of-life November 2020 and April 2015, respectively, so it is likely, whatever distribution you are using, that you are no longer receiving security updates (unless you are paying for them) and need to upgrade to a new version rather than attempt to employ such a solution.