connecting-securely

name	connecting-securely
description	Connect to the Yale SOM HPC cluster (hpc.som.yale.edu) over SSH with keys, agents, jump hosts, and tunnels — no copied private keys. TRIGGER when SSHing to the Yale SOM HPC cluster, setting up VS Code/Jupyter tunnels to a cluster compute node, forwarding ports through the cluster login node, or troubleshooting cluster SSH/agent auth.
related	["overview","staying-connected","managing-jobs","installing-software","using-gpus"]
updated	2026-06-05T00:00:00.000Z

Connecting Securely

Rule: use SSH keys and agent forwarding; never copy private keys onto the cluster.

Do not copy private keys

Bad:

scp ~/.ssh/id_ed25519 hpc:~/.ssh/

Good:

ssh-add -l
ssh hpc

If you need GitHub from the cluster, use gh auth login or carefully scoped SSH agent forwarding. Do not store your laptop private key on GPFS. If gh is not installed, see installing software.

Local SSH config

Example ~/.ssh/config on your laptop:

Host hpc
    HostName hpc.som.yale.edu
    User yournetid
    ServerAliveInterval 60
    ServerAliveCountMax 3
    ControlMaster auto
    ControlPath ~/.ssh/cm-%r@%h:%p
    ControlPersist 10m

Host b??? c???
    User yournetid
    ProxyJump hpc
    HostName %h.cm.cluster

ServerAliveInterval keeps NAT/firewalls from silently dropping an idle session; ControlMaster/ControlPersist reuse one warm connection across repeated logins. To keep long agent work alive across laptop sleep or wifi drops, see staying connected.

Enable ForwardAgent yes only if you need it for Git or another SSH hop. Agent forwarding is convenient, but any process you run on the remote host can ask your agent to sign while the connection is active.

Now login works:

ssh hpc

Only connect to a compute node after Slurm has allocated it to you. Use the hostname printed inside your allocation, then tunnel to that node.

Permissions

chmod 700 ~/.ssh
chmod 600 ~/.ssh/config
chmod 600 ~/.ssh/authorized_keys 2>/dev/null || true
chmod 700 ~

This is a shared system. Keep private files private: do not make your home directory, .ssh, .env, tokens, or project credentials group/world-readable.

SSH agent checks

ssh-add -l
ssh -T [e-mail]

Inside tmux or a long-running shell, SSH_AUTH_SOCK can go stale. The value is only a path to the forwarded agent socket created by your current SSH login; it is not the key itself. If GitHub auth worked yesterday and fails today, do not copy keys to the cluster. Start a fresh SSH login, restart the shell, or look into refreshing SSH_AUTH_SOCK so it points at a current working socket owned by you.

Principle: fix the pointer to your forwarded agent, not the location of your private key.

GitHub from the cluster

Preferred, after installing gh if needed:

gh auth login

Alternative with explicitly enabled forwarded SSH agent:

ssh -T [e-mail]
git clone [e-mail]:owner/repo.git

Jupyter tunnel pattern

On the cluster, allocate a small node and start Jupyter. Use the smallest allocation that fits your data, with an explicit short time limit — a tunneled Jupyter session is still an interactive job and holds those resources until you scancel it or the time limit hits.

srun --partition=cpunormal --cpus-per-task=2 --mem=8G --time=02:00:00 --pty bash
node=$(hostname)
echo "$node"
jupyter notebook --no-browser --port=8888 --ip=127.0.0.1

On your laptop, tunnel to the allocated node. Replace c018 with the hostname printed by hostname:

ssh -NL 9999:localhost:8888 c018

Open http://localhost:9999. When you are done, exit the notebook and the srun shell. Do not leave a Jupyter session running overnight.

VS Code / Cursor

Connect to hpc for editing. Connect to a compute node only after you have an active Slurm allocation on that node — never run heavy editor extensions or notebook kernels against the login node, which is shared by everyone.

You must be on a Yale network path to reach the cluster (Yale VPN/AnyConnect or campus network). Fix network access before debugging SSH keys.

Checklist

• Private keys stay on laptop or password manager, not the cluster.
• ssh hpc works.
• Compute-node SSH is attempted only for the node allocated to your job.
• GitHub auth works by agent forwarding or gh, not copied keys.
• Tunnels go to compute nodes, not login-node compute sessions.

Further reading

• ssh_config(5) — every ~/.ssh/config keyword (ProxyJump, ControlMaster, ForwardAgent, etc.).
• ssh-agent(1) — agent lifecycle, SSH_AUTH_SOCK, agent forwarding.
• VS Code Remote-SSH — connecting an editor to the cluster.
• GitHub CLI auth — gh auth login flow on a remote host.