Navigation :

Kerberos for Ubuntu

CSAIL Kerberos setup on Debian or similar non-CSAIL Ubuntu systems (Ubuntu, etc)

none of this is necessary on TIG’s supported flavor of Linux, [CSAIL Linux], which comes with Kerberos and OpenAFS already configured and integrated with the system.

apt-get install krb5-user krb5-config If prompted for a default realm, enter CSAIL.MIT.EDU making sure to capitalize it as shown.
Run kinit <username>@CSAIL.MIT.EDU to authenticate. The authentication tickets obtained here will expire after 10 hours, at which point you’ll no longer be authenticated.
By default, Kerberos tickets and AFS tokens expire automatically to protect your account. For automated tasks, long-running compute jobs, or persistent terminal sessions, you will need to use specific tools to prevent your Kerberos tickets from expiring. See the Guide to Long-Running and Uninterrupted Sessions for officially supported methods and important security policies.

SSH client configuration

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

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.

Local Steps on Your Linux Cleint

Create the control socket directory fro multiplexing ssh conenctions mkdir ~/.ssh/cm_socket
Add the following to ~/.ssh/config (create the file if it doesn’t already exist) for your user account only or to /etc/ssh/ssh_config for all users, so ssh will properly use your Kerberos tickets when logging in to CSAIL machines :

HashKnownHosts yes
VerifyHostKeyDNS ask
CanonicalizeHostname always
CanonicalDomains csail.mit.edu

# all  CSAIL hosts use GSSAPI
Host *.csail.mit.edu 128.52.* 128.30.*
  GSSAPIAuthentication yes
  GSSAPIKeyExchange yes
  # If you have a different local username uncomment the following line
  # and fill in your CSAIL UserName
  # User <CSAIL UserName>


# jumps reuse existing connections to minimise DUO prompts
# "ControlPath" must exist and cannot be in AFS
#
# NOTE: if you are on a laptop or other systems that switches 
# networks the Control Socket will need to be manually removed
# in order for it to get recreated on the new network:
#
# rm ~/.ssh/cm_socket/*
#
# The symptom is new ssh session hanging prior to connection
# It is always safe to run this command though it will require 
# Duo auth on re-establish the connection.

Host  jump.csail.mit.edu
  ControlMaster auto
  ControlPersist 1800

  ### This directory must be manually created! ###
  ControlPath ~/.ssh/cm_socket/%C

# CSAIL hosts except jumphosts get GSSAPIDelegateCredentials for AFS
Host *.csail.mit.edu !jump.csail.mit.edu 128.52.* 128.30.* 128.31.*
  ProxyJump jump.csail.mit.edu
  GSSAPIDelegateCredentials yes
  ForwardAgent yes

# if you ssh to ATHENA systems
# uncomment the lines below
# and edit to include your ATHENA Username
#Host !*.csail.mit.edu *.mit.edu
#  User <ATHENA UserName>
#  GSSAPIAuthentication yes
#  GSSAPIDelegateCredentials yes
#  GSSAPIKeyExchange yes

Note: The GSSAPIKeyExchange option requires a pathced version of OpenSSH. Most distributions do include this, but if you get errors it is safe to comment this option out and the rest of the config will work as expected.

VerifyHostKeyDNS will check the presented host key against the fingerprints we publish in DNS for this host and automatically accept them if they match. You can alternatively set this ask in which case you will get the usual prompt to accept new keys but will have the additional information that that Matching host key fingerprint found in DNS if all is well.

For ~/.ssh/config, make sure that you are its owner and no one else can write to it. For example:

$ chmod 600 config
$ chown $USER config