Introduction¶

Note: The following guide is for Linux/Unix based systems including Mac that use OpenSSH or a compatible ssh client. If you are using a Windows system, we recommend the official "Windows Subsystem for Linux" (WSL2) provided by Microsoft to create a linux system kernel and environment within Windows.

This will start with the basic configuration to tell your SSH client about specific hosts that you connect to. Different access parameters for each host can be independently specified here. By default, your ssh configuration file for your profile on your local machine will likely be located at ~/.ssh/config. Edit this file using a text editor of your choice.

Set Up Host Aliases¶

Let's create some host aliases for the CCI landing pads so that we can simplify our initial ssh command. Let's say that your CCI username was EXPLname. Typically, you'd connect to a landing pad through ssh with a command like:

ssh EXPLname@blp01.ccni.rpi.edu

You could add the following lines to your ssh configuration file:

Host cci01
        HostName blp01.ccni.rpi.edu        
        User EXPLname


Host cci02
        HostName blp02.ccni.rpi.edu        
        User EXPLname


Host cci03
        HostName blp03.ccni.rpi.edu        
        User EXPLname

Host cci04
        HostName blp04.ccni.rpi.edu        
        User EXPLname

This would allow you to refer to specific landing pads by an alias (nickname) instead of a full address. It also will use the configured username to connect to the specified host so your ssh command to connect to a landing pad would now be:

ssh cci01

This also affects SCP commands, so if you wanted to transfer a file test.txt that existed in your local machines home directory, you could now transfer it to your barn (or anywhere else) with the following command:

scp ~/test.txt cci01:~/barn/

Note: This SSH configuration file is also normally where you could supply specific public-key identity files for passwordless access. However, CCI systems require two-factor authentication with each new SSH connection and has disabled public-key authentication for off-site connections. As such, generating and configuring these identity files is not documented here. There is, however, a way to create multiple connections using only one authentication...

Remote Filesystem Mounting¶

Introduction¶

For users who prefer GUI file management, relying on editing your files using CLI text editors like vim, emacs, nano, etc. may be an inconvenient way to modify files. Alternatively, one could modify a file locally and then use SCP to transfer it to the CCI but this is also inconvenient and time consuming.

If you are one of those users, then there is a better solution: SSHFS: mounting CCI directories to your local machine. In other words, creating a directory that appears as if it were a natural folder on your computer but is constantly synchronized with a directory at the CCI. This synched directory includes all subdirectories and files within it as well. We can, for example, mount our CCI Home directory on our local machine over SSH and then edit the files locally using any text editor we'd like, CLI or otherwise! This includes vim, emacs, VSCode, Sublime, you name it.

Installation¶

The tool we'll use to mount a networked filesystem over SSH is called sshfs. Some linux distros might include it already but it may need to be installed on your local machine. For Ubuntu/Debian as an example, it can be installed with:

sudo apt-get install sshfs

Setup¶

First, for convenience and simplicity of this tutorial, we'll create a main directory that will contain all of our mount points and subdirectories in it for each of the directories we want to mount. It's also good practice to have this directory of mount points should you ever want to apply this technique to other network accessible servers.

mkdir ~/mounts
cd ~/mounts
mkdir home

Usage¶

Now that we've got the SSHFS tool installed and our mount point created, let's actually create the connection. The tool's usage pattern is as such:

sshfs <USERNAME>@<HOSTNAME>:/path/to/desired/directory /path/to/mount/point -o <OPTIONS>

For our example we're going to be mounting our home directory, this will allow us to navigate all of our immediately accessible files and directories such as barn, scratch, and similar. Let's say your CCI project and username are EXPL and EXPLname respectively, the command to mount your home directory to the mount point we created above is as follows:

sshfs EXPLname@blp01.ccni.rpi.edu:/gpfs/u/home/EXPL/EXPLname ~/mounts/home -o follow_symlinks

The -o follow_symlinks part is very important. Barn, Scratch, Barn-Shared, and Scratch-Shared appear as subdirectories within your home directory on the CCI systems, but they are actually symbolic links (symlinks in Linux lingo). Essentially they are shortcuts to where the directories are actually located within the CCI. Without this additional option provided to SSHFS, these shortcuts will appear as blank files to you on your local machine. With this option, SSHFS knows to keep an eye out for the shortcuts and populate them to their actual location when you try to access them locally.

To disconnect, close any windows or editors accessing the mounted directories and execute the following command:

sudo umount ~/mounts/home

You will be prompted for your local machine's sudo password. If this is unsuccessful and closing all windows and editors still doesn't work, rebooting the system will do the trick.

SSH Multiplexing Revisited¶

You'll notice that when you executed that sshfs command to mount your home directory locally, it asked for your PIC+Token and password. But what if we had set up SSH multiplexing (see above)?. This sshfs tool mounts the networked filesystem and synchronizes it all over SSH, which means if we had an established SSH control socket, we could direct sshfs to use that existing connection and not require another CCI authentication!

Assuming that you have set up your SSH configuration as specified in the above examples on SSH Multiplexing, we could instead make our sshfs command as follows:

sshfs cci01:/gpfs/u/home/EXPL/EXPLname ~/mounts/home -o follow_symlinks

If the control socket for cci01 exists, then it will use that; otherwise it will ask for authentication via PIC+Token and password.