SSH Access

DUO MultiFactor Authentication Required

Beginning August 5th, 2025, SSH access to CSAIL systems requires DUO MultiFactor Authentication (MFA).

This uses the same app as MIT DUO so most people will already have that installed and set up. If you do not, now is a good time to review their Knowledge Base article.

While we use the same application (and under their license), CSAIL has a separate DUO instance with separate configuration.

Signing up for CSAIL DUO

Sign in to https://duo.csail.mit.edu/ and configure your preferences.

If you attempt to SSH to systems that require DUO before this is configured, you will be denied access and presented with a link to configure your DUO preferences:

$ ssh user@login.csail.mit.edu
user@login.csail.mit.edu's password:
Please enroll at [https://api-f9e5e8b6.duosecurity.com/frame/portal/v4/enroll?code=1fc14591696012e7&akey=DAY2HO8ZVB7D9PBIZINN](https://api-f9e5e8b6.duosecurity.com/frame/portal/v4/enroll?code=1fc14591696012e7&akey=DAY2HO8ZVB7D9PBIZINN)
Please enroll at [https://api-f9e5e8b6.duosecurity.com/frame/portal/v4/enroll?code=1fc14591696012e7&akey=DAY2HO8ZVB7D9PBIZINN](https://api-f9e5e8b6.duosecurity.com/frame/portal/v4/enroll?code=1fc14591696012e7&akey=DAY2HO8ZVB7D9PBIZINN)
Please enroll at [https://api-f9e5e8b6.duosecurity.com/frame/portal/v4/enroll?code=1fc14591696012e7&akey=DAY2HO8ZVB7D9PBIZINN](https://api-f9e5e8b6.duosecurity.com/frame/portal/v4/enroll?code=1fc14591696012e7&akey=DAY2HO8ZVB7D9PBIZINN)
user@login.csail.mit.edu: Permission denied (publickey,gssapi-with-mic,keyboard-interactive).

That time-limited link will also allow you to configure your DUO settings (and yes, it is normal to see it 3x).

Using Yubikeys with CSAIL DUO (optional)

YubiKeys are hardware security tokens that can be used in place of the DUO smartphone app.

MIT IST provides free YubiKeys on request (Touchstone login required).

These are just the basic USB-A or USB-C tokens. If you want the micro versions that can stay in your USB port permanently or Bluetooth-enabled tokens, you’ll need to purchase them from YubiCo.

MIT YubiKeys come preprogrammed to work with MIT DUO, but you will need to bring the paper cover sheet it comes with to TIG so we can program your key to work with CSAIL’s DUO.

If you already have an MIT Key but have lost the paperwork, or if you’ve purchased your own YubiKey, you can still come by TIG and we can help reprogram the key to work with both CSAIL DUO and MIT DUO.

Minimizing Second Factor Prompts

The standard CSAIL jump host configuration uses SSH Multiplexing so that you will only be prompted for DUO authentication when you first connect. So long as you maintain an open SSH session through the jump host, DUO will not be required for subsequent connections through the jump host, even if they are to different endpoint hosts. After 30 minutes with no open connections, the multiplexing socket will time out, and on the next connection you’ll again receive a DUO prompt.

Dealing with “problem” clients and workflows

IDEs (VS Code, Cursor, PuTTY, etc.) and other interactive tools that use SSH

Many integrated development environments (IDEs) and other tools that use SSH behind the scenes provide poor or no UI to deal with entering a second factor. If you follow the Minimizing Second Factor Prompts instructions above and manually SSH to any CSAIL host before using the problematic tool, it won’t need a second factor to connect and everything should function normally. VS Code/Cursor (and presumably Claude) will never work with Kerberos for Windows, and will never work with controlpersist-style sockets on Windows because Windows does not support those socket types.

Automated non-interactive processes

TIG can create configuration exceptions for internal cluster communications and exceptions for limited-scope system accounts using SSH key authentication. This is not self-service and requires a security review and custom configuration.

Please contact help@csail.mit.edu to arrange for custom configuration and testing as soon as possible to ensure a smooth transition.

SSH access restrictions

Inbound SSH connections from outside the CSAIL network to most systems on the CSAIL network are blocked by default. Inbound SSH connections to the public login server login.csail.mit.edu remain open.

Connecting to Slurm compute nodes and cluster infrastructure requires routing through the CSAIL jump host (jump.csail.mit.edu), regardless of whether you are connecting from outside or inside the internal CSAIL network (Ethernet or CSAILPrivate).

Routing through the jump host is our default recommendation for all CSAIL systems. Setting up the jump host in your client SSH configuration ensures you can access all hosts and Slurm nodes seamlessly while minimizing DUO prompts.

While alternative access paths like the Campus VPN or IP allowlisting exist for general internal machines, they do not bypass the jump host requirement for Slurm nodes and will require interactive DUO authentication on every single SSH connection to CSAIL Linux hosts.

Using SSH with the CSAIL Jump Host

TIG provides a dedicated jump host (separate from the login servers) called jump.csail.mit.edu. This server is configured to allow only proxy connections, not interactive logins.

Connections through the jump host are multiplexed using ControlSockets so only the initial connection will require DUO interaction. Downstream hosts—including Slurm compute nodes—are configured to trust proxied connections coming from the jump host since second-factor authentication has already been enforced there. This satisfies cluster security policies, GREATLY reduces the burden of re-authenticating, and allows problem clients to avoid issues by piggybacking on existing multiplexed connections.

Setting up the recommended client SSH config allows you to transparently access all CSAIL systems and Slurm nodes from any network location.

Please see the applicable configuration options for your platform:

• CSAIL Linux includes jump host configuration to minimize DUO prompts by default
• macOS
• Windows
• Linux

Allowlist SSH server

If all else fails, or you have a server that:

1. needs to allow SSH from outside the CSAIL network,
2. is not on the guest network (128.31.0.0/24), and
3. has non-CSAIL users or an application restriction making it difficult to use a jump host configuration as shown above,

please open a ticket by sending email to help@csail.mit.edu with the names and IP addresses of the machines you’d like to register as SSH servers and an explanation of the reason you need to have a firewall exception made. Note that the servers in question must have a static IP address assigned. Additional documentation can be found elsewhere on this site for physical servers and OpenStack virtual machines.

Host key fingerprints

The SSH host key fingerprints for jump.csail.mit.edu are as follows:

  256 SHA256:JzCoiNEhMYREkmK0L0zC02qBueIpMNvpFTGTshS3sns root@jump1 (ED25519)
  256 SHA256:GQyNnNOiJI+Su6e7MVfbU20481pzA3C5oitAQkg/YRg root@jump1 (ECDSA)
  2048 SHA256:Bfer+kRBig6hSjvyfOuNFZBOWZ0MWWnhJFKQrj4lSHA root@jump1 (RSA)

for older SSH clients that use MD5 hashes:

  2048 0e:21:cc:30:c2:ee:c8:b8:37:6f:20:6f:0c:89:e4:23 root@jump1 (RSA)
  256 0a:25:98:44:ab:e3:95:af:e7:9f:23:0e:87:db:77:5e root@jump1 (ECDSA)

How to use public-key authentication

We don’t generally encourage public-key authentication to CSAIL because it’s not compatible with AFS home directories. However, you can still use it, with the caveat that your .profile or .cshrc files won’t get run when you log in, and you won’t have access to your home directory. To enable public-key authentication, you will need to create a symbolic link for the ~/.ssh/authorized_keys file to a directory that’s globally readable (according to its AFS access control list). An easy way to do that is:

  ln -s ../public/authorized_keys ~/.ssh/authorized_keys

Then put the public keys you wish to use in ~/public/authorized_keys (~/public will already exist and be globally readable unless you deleted it).

To get Kerberos tickets and AFS tokens once you have logged in, run renew. (If this command is not present, run kinit && aklog instead.)

Visual Studio Code

VSCode requires additional configuration to work on our login servers.

See: Using SSH with Visual Studio Code

What about mosh?

Some people use mosh to connect to hosts at CSAIL. (Without special steps, this breaks a bunch of things about Kerberos authentication and AFS, as described above for public-key authentication, so is generally only useful when connecting to hosts where your home directory is not on AFS – either research machines which are not running CSAIL Linux, or CSAIL Linux hosts without AFS home directories. There’s a way around this that we are working on testing and documenting.)

mosh uses its own protocol, based on UDP and Google’s Protocol Buffers library, and the mosh protocol is not restricted by our firewall. However, mosh does use your local SSH command to start the mosh-server process on the remote server, so you will need to configure SSH as described above.