Remote Access

We support remote access via ssh. For security reasons, we do not support telnet. Many computers are available for login.

  • Unix

    Most Unix-like systems (this includes Mac OS-X) possess the ssh command line utility.

    To run command line utilities in Mac OS X, you must first start a terminal application, which can be found in Applications * Utilities * Terminal.

    For example: 

    $ ssh username@classes.cs.uchicago.edu
Last login: Fri Apr 16 17:18:33 2004 from belmont.cs.uchicago.edu
$

  • Windows

    We suggest PuTTY.

SSH Tunneling

SSH Tunneling allows you to connect to internal CS servers, such as mysql dbserver.cs.uchicago.edu, from outside our network.
See our general documentation or task specific instructions:

File Transfer

We do not support FTP access. Instead, we recommend using sftp or scp (both use the ssh protocol underneath).

  • Unix

    Most Unix-like systems (this includes Mac OS X) possess the command line utilities sftp and scp.

    To run command line utilities in Mac OS X, you must first start a terminal application, which can be found in Applications * Utilities * Terminal.

    For example: 

    $ sftp username@classes.cs.uchicago.edu
Connecting to classes.cs.uchicago.edu...
sftp> get /etc/passwd
Fetching /etc/passwd to passwd
sftp> exit

    $ scp username@classes.cs.uchicago.edu:/etc/passwd ./passwd
passwd               100% |*****************************|  1088       00:00

  • Windows

    We suggest WinSCP.

Problems?

First, check that you are running the software we recommend above. If you continue to have issues with PuTTY, WinSCP, or the Unix command line utilities, please contact us at techstaff@cs.uchicago.edu. The more details you give us, the faster we will be able to diagnose your problem.

The command line Unix programs have manuals available via the man command.

You can get diagnostics by running the command line Unix ssh program in verbose mode.

For example: 

$ ssh -vv user@classes.cs.uchicago.edu
OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3, SSH protocols 1.5/2.0, OpenSSL 0x0090603f 
debug1: Reading configuration data /home/username/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to classes.cs.uchicago.edu [128.135.11.76] port 22.
debug1: Connection established.
debug1: identity file /home/username/.ssh/identity type -1
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type 'Proc-Type:'
debug2: key_type_from_name: unknown key type 'DEK-Info:'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /home/username/.ssh/id_rsa type 1
debug1: identity file /home/username/.ssh/id_dsa type -1

...more diagnostic info omitted...

Please include the entire diagnostic output in your problem report.

Passwordless Authentication

It is possible to use public key cryptography so that passwords are not neccessary to login to CS machines. To do this, you need to create a key pair: 

$ ssh-keygen -t rsa -N '' -f ~/.ssh/id_rsa
...
$ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
...
$ chmod 0600 ~/.ssh/authorized_keys

You should now be able to ssh between CS machines without a password.

What this does is change the burden of authentication from something you know (a password) to something you possess (the private key in the key pair generated above). Any entity that possesses the private key will be trusted as you by the system, so it makes sense to protect the private key. The above example uses the -N '' option to protect the private key with an empty passphrase (that is, no protection at all). You are trusting the strength of Unix file permissions to prevent a third party from accessing your private key, which is an unwise thing to do for a variety of reasons.

You can use a keypair more securely by encrypting the private key. Thus, if someone gets access to the raw private key file, they still need to decrypt it for authentication use. You can create a passphrase-protected key pair exactly as above, but leaving out the -N '' option.

However, if you do this, you have recreated the original problem you were trying to solve! You have just replaced typing an account password with typing a key passphrase every time you wish to authenticate. There is a solution though, that will make everyone happy, using programs called ssh-agent and keychain. Using them is the subject of the next section.

Passphrase-protected SSH Keys using ssh-agent and keychain

ssh-agent is a program that runs in the background and keeps a decrypted copy of your private key in memory. Thus, you reduce the number of times you need to type in your passphrase from once per authentication event, to once every time the machine gets rebooted.

Rather than trusting someone that has access to your private key file (as above), or knowledge of your CS account password (as if you had not created a key pair at all), ssh-agent moves the trust to processes running with your identity.

ssh-agent uses environment variables to locate the connection (socket) to a running ssh-agent. keychain manages starting an ssh-agent if necessary, unlocking a key for the agent to hold, and export the appropriate environment variables so that other processes can use the ssh agent.

If using a Bourne-style shell (such as bash) add the following lines to a shell init file (.profile, .bash_profile, or whatever is appropriate to your shell of choice): 

keychain id_rsa
. ~/.keychain/`uname -n`-sh

keychain, by default, is quite verbose. Once you are sure that it is working the way you intend, throw a -q option onto the keychain invocation to silence it.

Further information: