Connecting with SSH/SCP/SFTP

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.

Contents


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 resides in /opt/openssh/bin/, which 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:

  • linux machines recommend you use 'ssh -X username@hostname' to connect.
  • OS OX machines need to use 'ssh -Y username@hostname' instead.

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.