Sorry, you need to enable JavaScript to visit this website.

HOWTOs

HOWTOs

Account

Password Policy Documentaion

You can find RIT's offical password policy here.

Changing your DCS password

You must be logged on to one of the Linux machines in the department. You must use the 'cspasswd' program found in /usr/local/dcs/bin. (this will be in your default path if you have not changed your dot-files)


If you can not remember your CS password you must visit the System Admin office found in room 70-3590.
We WILL NOT give you passwords over the phone or through email.
Any problems or questions you have can be sent to problems@cs.rit.edu

Password Strength

At this time the Department of Computer Science requires you password to be:

  • At least 8 characters long, 12 or more is recommended.
  • Passwords must be made up of 3 of 4 character types (first and last characters do not count towards the total):
    1. uppercase letters
    2. lowercase letters
    3. numbers
    4. punctuation characters
  • not containing any dictionary words if it is less than 12 characters long.

Remote Connections

Using puTTY

Getting PuTTY

PuTTY is a free SSH client available from http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html From that page you can download either just the putty.exe program or a full set of SSH utilities including file transfer and key generation. Note that PuTTYtel will not work to connect to the CS department, as we do not support telnet connections.

Quick Connection

When you launch the PuTTY.exe program, it shows a configuration screen with many options. However, most of them can be left at their defaults. To connect to a CS department computer, enter the fully qualified domain name (example: newyork.cs.rit.edu) in the text box labeled "Host Name (or IP address)". You can then click the "Open" button to connect. The first time you connect to a host, it will display a security alert. You can usually click "Yes" and it will remember the host key and not prompt the next time you connect (see below for more details). After it connects, it will prompt for your username and password.

When connecting to a host for the first time or for the first time after a host's SSH keys (these are not your personal keys, but the keypair that identifies a particular computer system) have been rebuilt, you will be prompted with a message similar to:

The server's host key is not cached in the registry. You have no guarantee that the server is the computer you think it is. The server's rsa2 key fingerprint is: ssh-rsa 1024 03:90:56:97:64:e4:e3:24:12:ed:f8:a8:7e:04:1f:46 If you trust this host, hit Yes to add the key to PuTTY's cache and carry on connecting. If you want to carry on connecting just once, without adding the key to the cache, hit No. If you do not trust this host, hit Cancel to abandon the connection.

In general it is perfectly safe to hit Yes at this prompt. If you know the SSH keys on a host have not changed (this is most applicable to users running Unix at home) but you are being prompted with a message similar to the above, please contact the Admins immediately.

Saving a Session

To avoid having to type in a host and your user name every time, you can save the settings as a session. To do so, enter in a host name and set any additional settings (such as username under the "Connection/Data" category), then enter a name under "Saved Sessions" (in the main "Session" category) and press "Save". From then on, you can simply double-click the session name in the list to connect to that machine. You can use the "Load" button to bring up the settings in order to change them and then save them again under the same name or a new one.

Generating SSH Keys

PuTTY also comes with a program named PuTTYgen to generate SSH public and private keys. You can use these keys to authenticate instead of using your password.

Using SSH/SCP/SFTP

General Disclaimer

This is not a guide on how to use SSH/SCP/SFTP or any mail or news programs. There are far too many programs to write a comprehensive guide on each. Instead, this will serve as a general usage and configuration primer for the programs most readily available in the Department of Computer Science at R.I.T. All systems in the Computer Science Department are configured to use SSH2 only. There are a number of well-documented security vulnerabilities of SSH1 that SSH2 is immune to, so fallback to SSH1 has also been disabled.

Valid machines for general use are all student labs (ICLs 1-4) and the general access SMPs. When you are in a lab you will see name tags on each system; simply append '.cs.rit.edu' to the name for the fully-qualified DNS name. For example, the host idaho is really idaho.cs.rit.edu.

One machine not in labs that is a valid connection point is glados. This is a larger system available for general computing use, living in the Computer Science machine room.

When connecting to a host for the first time or for the first time after a host's SSH keys (these are not your personal keys, but the keypair that identifies a particular computer system) have been rebuilt, you will be prompted with a message similar to:


The authenticity of host '{hostname} ({host IP address})' can't be established.
RSA key fingerprint is 03:90:56:97:64:e4:e3:24:12:ed:f8:a8:7e:04:1f:46.
Are you sure you want to continue connecting (yes/no)?


In general it is perfectly safe to accept this prompt. If you know the SSH keys on a host have not changed (this is most applicable to users running Unix at home) but you are being prompted with a message similar to the above, please contact the Admins immediately.

Authentication with SSH

SSH supports multiple user authentication techniques. The two employed by the CS department are password-based and public/private key-based.

Using Password Authentication

This is the default technique; simply follow the directions for connecting to a CS host below. When connecting, you will be prompted for your password.

Using Public/Private Keys for Authentication

This technique requires the building and distribution of SSH keys.

Note that this method is generally not available for Windows systems. The password authentication technique is sufficient.

The command ssh-keygen should already be in your path.

The default behavior of the SSH key generator is to build 1024-bit RSA keys for SSH verison 2.

Building & Using SSH Keys
  1. At the Unix shell, enter the following command:

    $> ssh-keygen -b [1024 | 2048] -t rsa {enter}

    where you choose either 1024- or 2048-bit key length (longer keys = greater security at cost of greater computation time and effort).

    When prompted for a passphrase, it is important that you not leave this blank. It is also best to not make this passphrase the same as your password. Using your password as the key passphrase is essentially identical to using password authentication.

    This will create a file pair ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub. The id_rsa.pub file is your public key, the file without the extention is your private key.

  2. At the Unix shell, enter the following command:

    $> ssh-keygen -b [1024 | 2048] -t dsa {enter}

    where you choose either 1024- or 2048-bit key length (again, longer keys = greater security at cost of greater computation time and effort). Also, note the algorithm difference (the first invocation generated RSA keys, this builds DSA keys).

    When prompted for a passphrase, it is important that you not leave this blank. It is also best to not make this passphrase the same as your password. Using your password as the key passphrase is essentially identical to using password authentication. For simplicities sake, this can be the same as your RSA keypair, but additional security is gained (in the sense that for full compromise of your keypairs it would require crack two passphrases, not just one) by making the two passphrases different.

    This will create a file pair ~/.ssh/id_dsa and ~/.ssh/id_dsa.pub. The id_dsa.pub file is your public key, the file without the extention is your private key.

When you distribute keypairs keep these points in mind:
  • In the CS department, all systems have a common filesystem. This means that in effect, for every two CS systems you move between, your SSH keys are already distributed.
  • File system permissions on both the public and private keys should be 0600 (readable and writable by you only).
  • If you want to connect to the CS systems from home, generate keys at home the same way as above, and simply copy your public key file to the CS systems. This is not a simple copy; it is important to follow these directions:
    • Say on the CS systems you have your public/private keypairs. When importing a new public key, save the new public key as a separate file.
    • Enter the following command to import a new public key:

      $> cat {new public key file name} >> ~/.ssh/authorized_keys {enter}

    • You should now be able to hop between hosts and authenticate using your SSH passphrase.
Now when using SSH you will not be prompted for your password but rather the passphrase you entered when generating the keys. This can be further simplified by using SSH agents. Depending on the authentication method chosen by the SSH handshake process, this is using either RSA or DSA keys; if your passphrase is different for each keypair, this will matter. SSH will default to RSA keys first, and then moving to DSA keys.  For more on this, see the Resources section.

So, Instead of My Password I Have a Passphrase -- Why Bother?
This point could be argued either way, but perhaps the most appropriate point is separation of authority. If one password is used everywhere, this is a single point of failure. If you use a password or second passphrase to log onto the CS systems, and then a different passphrase to move between the department (this scenario as follows: connecting to the CS department from home with SSH keypair A or via password authentication, and using SSH keypair B within the department), this is two levels of security.

General Notes on Authentication

Keys are the prefered method of authentication. As mentioned above, RSA keys are first tried, then DSA keys. If keys are non-existant or fail authentication (incorrect passphrase, etc), password-based authentication is used.


Connecting to a Machine Via SSH from OS X/Unix

Provided you have a CS account, from a Unix shell enter either of the following commands at a shell prompt:

$> ssh {username}@{machine name} {enter}

or

$> ssh -l {username} {machine name} {enter}

where {machine name} is either a fully qualified DNS name (eg. tin.cs.rit.edu) if you're connecting from outside the department, or just the hostname (eg. tin) if you're connecting from within.

If you're connecting two systems on which you have the same username, (ie, between two CS systems) you may ommit the {username} field; it defaults to the username you are currently using.

Use the default SSH port (TCP port 22) when connecting.

This technique works equally well for any other Solaris, Linux, or other Unix variant Operating System.

Connecting to a Machine Via SSH from Windows

Prerequisites:
  1. CS account
  2. SSH client for your version of Windows; suggested clients are:

Configure your client to connect using your CS username to a valid CS Department host. As with the Unix variants, your host specification is either a fully qualified DNS name (eg newyork.cs.rit.edu) if you're connecting from outside the department, or just the hostname (eg newyork) if you're connecting from within.

Use the default SSH port (TCP port 22) when connecting (there may be an option to change this value; leave it as is).

Getting a Windowing Environment -- When a Shell Isn't Enough

The above products will provide a secure shell, which does not permit multiple windows (eg, you won't be able to start emacs and maintain your shell window). If this is a desirable feature you will need to have an X Server running on your local machine. Please check out these How Tos: Also note:

Using SCP and SFTP

These programs operate as a subset of the SSH package, and therefore are restricted to the hosts and protocols as mentioned above.

One Important Caveat About SCP and SFTP:

If excessive information is echoed to the terminal during login (from the .login or .bashrc/.cshrc files), these two programs will not work. RationalRose, as used in CS4 and CS for Transfer classes, also causes these programs to fail as they echo information to the terminal window.

Simply commenting out the appropriate lines in these files will allow SCP and SFTP to operate cleanly.

In your .cshrc or .bash_profile file, a line similar to:

source /usr/local/RationalRose/rs_setup.csh

exists; inserting a pound sign (#) before this line will comment it out and prevent its execution.

SCP

scp works like the unix 'cp' command, except it copies from between hosts.
A simple syntax (man scp for more options): 
scp [ [user@]host1:]file1 []... [ [user@]host2:]file2
If user or host is omitted, it assumes your userid and local host.
example: 
scp file1 username@holly.cs.rit.edu:/full-path-to-home/file2
This will copy file1 from your current machine and directory to /full-path-to-home/file2 through the machine holly. You will be required to authenticate as username for the process to succeed.

SFTP

SFTP works the same as traditional ftp, except over a secure connection. To use it, just connect to any of the lab machines.
Example: 
sftp newyork.cs.rit.edu
After authenticating, you will be connected to your home directory. See the man page for sftp for more details.

Advanced: Using ssh-agent from OSX/Unix

Using ssh-agent can greatly increase automation when working on a distributed project while continuing to be secure. It allows you to use a passphrase protected ssh generated key without having to type in the password each time. This is done by starting a process that will act as a password proxy for your current shell session. This process is separate from the shell you invoke it from: it will be important that you kill that process before you close the shell. Otherwise, you will leave orphaned ssh-agent processes behind
To get ssh-agent to work for you, you must already have ssh keys generated (see Using Public/Private Keys for Authentication ).
  1. Open up a shell window on your Unix machine.
  2. Depending on what your default shell is, you will need to start ssh-agent
    • If using bash, dash, or sh, eval 'ssh-agent -s'. (the ' is important here)
    • If you use csh, tcsh, eval 'ssh-agent -c'
    This will take the output of the ssh-agent command as commands to be run. In this case, they will be values set in your shell. This will give your current shell session the information it needs to use the ssh-agent as a proxy.
  3. You will be able to now add an ssh key to the agent for proxy. ssh-add ~/.ssh/id_rsa (or id_dsa, or whatever name you gave your ssh keys). It will ask you for the passphrase. Type this in to unlock the key and add it to the agent.
  4. You can now use ssh to reach other machines with that key, and not require you to type in that passphrase each time.
  5. NOTE: When you are done with the current shell and logging off, please kill the process of the agent. It can be found typing echo $SSH_AGENT_PID
  6. NOTE: Only the shell that has the SSH_AUTH_SOCK and SSH_AGENT_PID variables set will have access to the agent. Unless you chose to add them by hand to other shell sessions, only the shell session you ran eval 'ssh-agent -s' will have a connection to the agent.
Using X11 with OS X

Installing X11

How to intall X11 depends on what version of OS X you have installed:

10.2 and earlier
No official versions of X11 exist for these versions.
10.3 (Panther)
X11 is available from Apple's website
10.4 (Tiger)
X11 is an optional installation from the Tiger DVD.
10.5 (Leopard) and later
X11 is installed by default.

Running X11

Recent versions of OS X will automatically launch X11 when a program attempts to connect to the X server. Open Terminal.app and try running xterm. If that doesn't work, you'll need to start X11 manually. It can be found in /Applications/Utilities.

Using X programs from the CS machines

Using the Terminal or an xterm, use ssh -Y username@hostname to connect to a CS machine. Once logged in, you may use programs as normal. For example running emacs should open the emacs window on your computer.

Using xming

Before going any further, you should have downloaded Putty already. Documentation on getting Putty is available here.

Getting Xming

  • Go to straightrunning.com/XmingNotes to download Xming.
  • Scroll down to Releases and under Public Domain Releases, click on Xming to download.
  • Run the .exe setup file
  • If you run into firewall problems, click “Allow access” to continue
  • Continue through the installer until “Finish”

Configure Xming for the first time

  • First, type and click XLaunch from the start menu to launch Xming
  • Choose display setting and display number and click Next
  • Click “Start a program” and Next
  • Chose “Run Remote” “Using Putty (plink.exe)”
  • Enter the IP address of the machine to which you want to connect. For Glados, for example, enter 129.21.30.38 or glados.cs.rit.edu
  • Enter your RIT username in “login as user” box
  • Enter your CS password in “Password” box
  • Click Next and Next
  • Under “Configuration Complete” Click on “Save configuration” so you don't have to launch xming each time you want to connect to the same machine
  • Click Finish

Configure Putty with Xming

  • Now, run Putty
  • Under Putty configuration window, select “Connection” on the left panel
  • Under SSH click on X11 on the left hand side menu
  • check “Enable X11 Forwarding”
  • Now, click “Session” at the very top of the left hand side menu. Scroll to the top if necessary
  • Fill in “Host name” box: IP address of machine
  • Makes sure the “Port” number is 22
  • Enter a name for this session under “Saved Session” box
  • Click on “Save” to save session – Refer here for more info
  • Then click Open to connect
  • You will be then prompted to enter your computer science username and password
  • Enter the name of Linux app you want to use, for example, libreoffice

Mail

pine / alpine with IMAP

General Notice

pine is available on the Solaris machines.
alpine is the replacement mail tool and currently is only found on the Ubuntu machines.

/var/mail is NFS mounted on the Solaris machines, which allows pine to read your inbox without the need for IMAP. This functionality is going to go away as the Solaris machines are phased out. There are no plans to mount /var/mail from the Ubuntu machines which is why you will need to set alpine up to read mail through IMAP

Setting up (al)pine to use IMAP

Once you start alpine, at the main screen hit 'S' then 'C'
(S) Setup -> (C) Config::

User Domain = cs.rit.edu
SMTP Server (for sending) = mailhost.cs.rit.edu:587/tls
Inbox Path = {mailhost.cs.rit.edu/user=username/ssl/IMAP}INBOX

where username is your CS username, ie. abc1234

choose 'E' to exit setup and confirm the changes.

To read your inbox type in your CS password at the promt. Then 'L' Folder List -> 'M' Mail -> INBOX

procmail- forwarding email and spam filtering

procmail can be used to filter and forward your cs email. By default new students have their cs accounts set up with procmail to forward email to username@rit.edu.

to use procmail, you first need to

  • set up a ~/.qmail file with the following line:
|/usr/local/bin/qmail-procmail
  • set up a ~/.procmailrc file:
    • #=====================#
# Filter out the spam #
#=====================#
:0:
* ^X-Spam-Status: Yes
/your-home-path/mail/caughtspam

    That simple example will filter any mail that the system tags as spam and put it into your ~/mail/caughtspam file.

    procmail will process your .procmailrc file until it finds a matching rule and then exit after following that rule. If procmail does not find a matching rule by the end of the file, the message will be put into your cs mail folder. So, if what you want to do is send all of your mail somewhere else, you could forward it at the end of your .procmailrc

    Forwarding

    If you want to forward your mail to another site you can add the following lines to the end of your ~/.procmailrc file: 

    :0
! your@email

    Don't forget to have your .qmail file process mail through procmail: 

    |/usr/local/bin/qmail-procmail

    Other Resources

    This is a very simple procmail set up, but you can get more help from the following resources:

    Window Managers

    fluxbox

    What is Fluxbox:

    It is a window manager for X window system. The user interface is very lightweight and simple. More info can be found here.
    • A right-click on the desktop will open main menu where you can customize the style, select applications, and change configuration. Alternatively, you can go to fluxbox directory, usually it is ./fluxbox/ where you can modify files directly.
    • Middle click or Left click on desktop will open workspace menu
    • Running programs are by default at the bottom of the screen
    • Common shortcut can be found here. Scroll down to “Key Bindings”
    • Fluxbox manual page can be found here.

    Using Fluxbox

    • Go to fluxbox directory and do startfluxbox to start a fluxbox session
    • If there is no error message, skip the steps below
    • If you get error, you have a running window manager already running, do the below steps
    • Log out
    • At the login prompt, click options and choose fluxbox from the list of window managers and login as usual

    Customization

    • Customization is done by editing configuration files in the .fluxbox directory in user home directory.
    • Keyboard shortcuts are stored in the ~/.fluxbox/keys file
    • Menu layout is in the ~/.fluxbox/menu file
    • Everything running at startup is found in ~/.fluxbox/startup
    • Configuration file ~/.fluxbox/init
    vtwm

    What is VTWM

    vtwm is a window manager for the X Window System. It provides titlebars, shaped windows, several forms of icon management, user-defined macro functions, click-to-type and pointer-driven keyboard focus, and user-specified key and pointer button bindings.

    Setting up the VTWM window manager:

    • Find these two files in home directory: .xinitrc and .Xsession
    • Make sure to include this line at the end of both files: vtwm>/dev/null 2>&1
    • Change permission of the two files to executable using: chmod u+x .xinitrc and chmod u+x .Xsession
    • Log out of current session
    • At the login prompt, click option and choose custom
    • Go back to the login prompt and login as usual
    • Your running program will be listed at the top left corner
    • To access main menu, left click and hold on the desktop
    • To log out, left click and hold on exit and click quit