Remote Access

From Earlham CS Department
Revision as of 14:22, 21 January 2009 by Kay (talk | contribs) (ssh)
Jump to navigation Jump to search

The CS department systems administrators support a number of ways to access departmental computing resources remotely.

File transferring


FTP stands for the File Transfer Protocol. The systems administrators support FTP access on the main file server, Quark. To access this open up an FTP client on your machine, and point it at



To access the graphical client, go to "My Network Places", select "Add Network Place", and plug in, uncheck "Log in anonymously" and give it your CS username. You will be prompted for your password later. You can drag files or folder in and out of the FTP window to transfer them.


To use the text FTP client, go to Start→Run and type in "ftp". You will be prompted for your username and password. The navigation commands are the same for Linux, so you can "cd" into directories. To put a file, type in "put /path/to/local/file". To get a file, type in "get /path/to/remote/file". Be sure to type in the "bin" command before doing any transfers! Windows is brain-dead and will corrupt any binary file you transport unless you give it that command.


See the disucssion of Windows text-mode FTP above.


SCP stands for secure copy, and SFTP stands for Secure FTP. These two utilities connect to an ssh server running on a remote machine and copy the file encrypted. It will even encrypt your username and password so that malicious crackers cannot sniff your network traffic for that information, as is the case with FTP. sftp uses the same command set as FTP. scp works like this:

$ scp user1@remote:/path/to/remote/file /path/to/local/directory


$ scp /path/to/local/file user1@remote:/path/to/remote/directory

Run "man scp" for more information.

Shell access

The CS department provides remote shell access to all servers and workstations. This allows command-line interactions with the machines from anywhere in the world. If you are on a machine with an X Windows server, you can even run graphical applications remotely and have them display locally.

Discussion on telnet

Some people wonder why the CS department doesn't support telnet any more. The reason is simple: it's insecure, and its replacements have the same (and even greater) functionality with many orders of magnitude more security. Face it: telnet is dangerous when used to connect to a telnet server. There's nothing you can say that will make it come back.


ssh is an encrypted protocol that provides, among other things, secure remote shell access. The systems administrators support ssh on all servers (such as Quark), and workstations (such as the ACLs). ssh ships with modern UNIXs (including Mac OS X), but you must download a client for Windows.

A popular choice is PuTTY. Download the putty.exe file for your system onto your desktop, and run it. You'll get a "PuTTY configuration" dialog. Put in the hostname of the machine you want to connect to (i.e., and select "SSH" in the protocol dialog. You can save this session by typing in a profile name in the "Saved Session" dialog.

PuTTY supports a few options that you might find useful. In the "SSH" menu on the side, selecting "SSH protocol version 2" will provide some extra security by using DSA rather than RSA keys. If you run a local X Windows server, you can enable X11 forwarding by going to the "Tunnels" submenu of "SSH".

Graphical access

The systems administrators also support graphical access to the ACL workstations over VNC (Virtual Network Connectivity). For Windows, a popular choice is TightVNC. Download the Windows exe file, and install it. You will get a client icon on your desktop. To use that, you must first start up a VNC server on an ACL. ssh into the ACL, and run the command "vncserver -depth 16". This will startup a VNC server on that ACL. Remember the hostname:desktop combination that it prints out. Back on your machine, run the client program and give it that hostname:desktop pair.

Encrypted access

In order to encrypt your VNC session, you must tunnel it through ssh. Besides providing remote shell access, ssh can also encrypt arbitrary data streams, and VNC really is nothing more than that. When you do this, the client will think it is talking to a local server, and remote server will think that the client is running on the same machine.

To do this in UNIX, run a command like this:

ssh -f -N -L 5999:remoteserver:5901 localhost

This links the local port 5999 to the remote port 5901. This means that if the you type in something like "vncviewer localhost:99" will actually be the equivalent to the unencrypted "vncviewer remoteserver:1". Remember that the VNC ports are in the range 5900--5999, and you only use the last two digits with vncviewer.

In Windows, you can use PuTTY to do this. Open up a saved profile for an ACL, and go down to the SSH→Tunnels menu. In the "Source port" field, type in a number like 5999. In the destination field, type in "", where n is the number of the ACL that your VNC server is running on, and xx is the port number that vncserver told you to connect your client to. Now, if you point VNCViewer to "localhost:99" (or whatever port number you put in), you will be redirected over an encrypted channel to the ACL.