the SSH feature that saved my sanity on PARAM Shivay

For my UG project, I needed to run some computationally heavy workloads, and my department gave me access to PARAM Shivay, IIT BHU's supercomputer under India's National Supercomputing Mission. It has GPU nodes, a Slurm scheduler, and a bunch of preinstalled modules for scientific computing. Great resource. Painful to actually use.

The problem starts the moment you try to connect. Every SSH session demands three separate rounds of authentication:

If you truly desire access to this host, then you must indulge me in a simple challenge.
-------------------------------------------------------------
 
Observe the picture below and answer the question listed afterwards:
  _   _   _   _   _   _   _   _  
 / \ / \ / \ / \ / \ / \ / \ / \ 
( j | P | H | w | B | E | F | M )
 \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ 
 
Type the string above:

A text CAPTCHA. Then a TOTP code. Then your password. Every. Single. Connection.

You can't add your public key either. The server config doesn't allow it. So there's no way to skip any of this.

the VS Code plan that didn't work

My first instinct was to use VS Code Remote SSH. Open a remote folder on the supercomputer, edit files, run terminals, the whole thing. The problem was immediately obvious: VS Code Remote SSH opens multiple SSH connections per session (one for the extension host, separate ones for file browsing, terminals, etc.), and each one would need to go through the full CAPTCHA -> TOTP -> password gauntlet. VS Code has no mechanism to handle that kind of interactive multi-step auth. It only supports typing a single password.

So I tried a different angle: set up ControlMaster to authenticate once and reuse the connection for everything else. That part worked. VS Code would only need to authenticate on the first connection, and every subsequent one would be instant.

Except it still didn't work. VS Code Remote SSH requires glibc >= 2.28 and libstdc++ >= 3.4.25. PARAM Shivay runs CentOS 7 with glibc 2.17, released in 2012. CentOS 7 is explicitly listed as unsupported with no workaround. VS Code connects, tells you the host isn't supported, and that's that.

VS Code was out entirely, not because of the auth, but because the OS was too old. The ControlMaster setup I'd put together was still useful though, just for regular terminal use.

what ControlMaster actually does

SSH has a multiplexing feature that lets multiple sessions share a single underlying TCP connection. Once you've authenticated once, every subsequent connection to the same host reuses that existing socket, with no re-authentication needed.

The relevant config in ~/.ssh/config:

Host param-shivay
  HostName <ip-or-hostname>
  User <your-username>
  ControlMaster auto
  ControlPath ~/.ssh/sockets/%r@%h:%p
  ControlPersist 600

ControlMaster auto: When set to auto, SSH will use an existing master connection if one is open, and create a new one (becoming the master itself) if not. The other values yes and no are more explicit, but auto is almost always what you want.

ControlPath ~/.ssh/sockets/%r@%h:%p: The path to the Unix domain socket that the master connection creates. %r, %h, and %p expand to the remote username, hostname, and port. The socket ends up at something like ~/.ssh/sockets/user@hostname:22. Make sure the directory exists: mkdir -p ~/.ssh/sockets.

ControlPersist 600: Without this, the master connection closes as soon as the first session exits. With it, the connection stays alive in the background for 600 seconds (10 minutes) after you disconnect. This is what makes it actually useful day-to-day. You open a session, do your work, close it, and any new connection within 10 minutes skips auth entirely.

in practice

The first time you connect, you do the full thing: CAPTCHA, TOTP, password. After that:

# first connection, the full ritual
$ ssh param-shivay
# ... CAPTCHA, 2FA, password ...
[param-shivay ~]$ exit
 
# any subsequent connection within 10 minutes, instant
$ ssh param-shivay
[param-shivay ~]$

No prompts. Works for scp and rsync too, since they use SSH under the hood. You can check if a master is running:

$ ssh -O check param-shivay
Master running (pid=12345)

And kill it early if needed:

$ ssh -O exit param-shivay
Exit request sent.

a note on security

The socket file is the only thing standing between an attacker and an authenticated connection to the remote host. Anyone who can read that socket on your local machine can connect without authenticating. On a personal laptop this is fine. On a shared workstation, be more careful: either shorten ControlPersist or make sure the socket directory has tight permissions (chmod 700 ~/.ssh/sockets).