☰
Navigation :

SSH Access

SSH access restrictions

Inbound SSH connections from outside the CSAIL network to most systems on the CSAIL network are blocked by default. SSH connections within the CSAIL network (either on Ethernet or CSAILPrivate) remain open. Inbound SSH connections to the public login server login.csail.mit.edu remain open.

To SSH to systems from outside the CSAIL network, you have 3 options:

  1. Use the MIT VPN for SSH access
  2. Use the CSAIL jump host for SSH access
  3. Allowlist an SSH server

MIT VPN access

The simplest way to access your systems within CSAIL from outside the CSAIL network is to use the Campus VPN, which is allowlisted.

No additional configuration is required while connected to the campus VPN. If you’d prefer not to use the VPN, follow the instructions below to configure your SSH client to use our jump host.

Using SSH with the CSAIL Jump Host

TIG is supplying 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.

Despite the impending network restrictions most people can continue to transparently access all CSAIL systems by setting up their client ssh config.

Please see the applicable configuration options for your platform

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.)

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 (128.31.0.0/24) or W3C (128.30.52.0/22) network, and
  3. has non-CSAIL users or some application restriction making it difficult to use a jump host configuration as shown above),

please open a ticket by sending mail to help@csail 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.

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 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.

One user reports that he needed to add --experimental-remote-ip=remote to the mosh command line to correctly connect to the server.

Why are you doing this?

After a spate of intrusions related to remote attackers using SSH servers to enter and compromise CSAIL servers and to attack outside networks from CSAIL, TIG came to two conclusions:

  1. There is so much noise caused by the large “background radiation” of brute-force attacks that it is very difficult to identify successful attacks by examination of logs alone.
  2. There are too many unmanaged systems on the CSAIL network that offer a public SSH service for the mitigations that we have employed so far to be sufficiently effective.

We want researchers to continue to be free to do their research without having to constantly ask for permission to connect devices to the network. However, we want to provide additional protection to the CSAIL network because many machines that users bring in to CSAIL were not designed for security, are often unmaintained for long periods of time, frequently come with weak and well-known default account credentials, and are easily compromised by a remote attacker simply scanning for known vulnerable devices. This can happen even with the official CSAIL Linux distribution: our mitigations assume that the system is operating properly, our configuration management system runs, kernel updates get installed regularly, and the disk doesn’t fill up preventing logs from being stored.

Restricting incoming SSH connections to specific, pre-registered hosts allows us to limit the attack surface and concentrate our prevention efforts on fewer than the thousand-plus machines on the CSAIL network. In the case of user-administered machines, it also gives us an opportunity to communicate security practices to the operators of those servers.