SSH

From Peyton Hall Documentation
Revision as of 18:47, 3 May 2007 by Huston (talk | contribs) (Lived on the edge long enough.. time to save a copy)
Jump to navigation Jump to search

Template:oldfaq Here you'll find all you need to know about Secure Shell (SSH) and its usage as required in Peyton Hall


Introduction

What is SSH?

SSH is a secure networking protocol that uses public key encryption to make sure that all data, including authentication data, is encrypted from end to end. It is similar to 'telnet' in only the fact that it lets you connect to remote computers. However, with 'telnet', 'ftp' and other insecure protocols, your user name and password are sent in cleartext to the remote side - they can be sniffed out anywhere along the network and your password recovered from the traffic. SSH uses encryption to make sure that your password is kept safe - and in fact, can be set so that your password is not even used.


Why should I use SSH?

SSH is required for all logins for security issues (described above). In a switched ethernet environment like ours, cleartext passwords aren't too much of a problem, since there's very few places where one could put a "sniffer" (which captures the network traffic) to read your password. However, in some cable modem setups and even DSL, other people can read the traffic that comes from your computer. If they're looking, and you telnet in at that moment, they've now got your user name and password and can login as you. What's more is that they may be able to exploit deficiencies in the Unix OS from that point to gain root access, and destroy data for not only you but anyone else in the department. This is not a Good Thing.

Because of that, we require that all incoming connections use SSH. We also require that all connections (except those to "Minos") use no password at all, instead using SSH public key authentication (see *IMPORTANT SSH Login Policies*). By restricting logins this way, we are able to allow logins to any machine in the building, from any machine in the world.


SSH versions

All machines in Peyton Hall run a version of OpenSSH. This was chosen over the version available from SSH Communications Security because it's free, usually gets updated more frequently, and comes with Fedora, and even MacOS X. There are a handful of other SSH programs available (see below) for other operating systems and environments. However, most have a few things in common:

  • The ability to use passwords over an encrypted link for authentication
  • Use of public key encryption for authentication
  • Tool for generating/converting keys
  • Ability to tunnel other ports through the SSH connection


Where to get SSH


Setting up a SSH environment

I have written a script called 'ssh-setup' to get you started with SSH. This will walk you through setting up a key, getting it used for authentication, and show you how to use it daily. You can run this script by entering "ssh-setup" at the command line on any of the linux machines in the department. This script will NOT explain all the details of usage, just a basic overview to get you up and running quickly; however, you will need to do a little more research to learn the details of usage. Because SSH is a complex program and protocol, there is no way to just hand you all the information you will need, so after running the script and getting some of the basics, read on for more information.


Keys

Before you can use SSH to the fullest extent - and in fact, before you can use it in Peyton Hall to login to another machine, you must create a keypair. There are a few different kinds of keys, which we'll go over here now.


DSA

The first type of key we'll go over is the DSA key (in fact, if you only want to create one key, this is the one). DSA keys use the SSH version 2 (SSHv2) protocol, which is more popular and more secure than the older SSHv1 system. To create a DSA key, run the command: 

ssh-keygen -t dsa

This will generate output that looks like this (don't worry, we'll go over the parts in a moment): 

Generating public/private dsa key pair.
Enter file in which to save the key (/u/user/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /u/user/.ssh/id_dsa.
Your public key has been saved in /u/user/.ssh/id_dsa.pub.
The key fingerprint is:
e0:48:7e:47:5c:5e:6a:ad:71:f1:eb:47:b1:ab:ae:6d user@machine.Princeton.EDU

Now, the questions asked above and what they mean:

  • Enter file in which to save the key
    If you want the key to go to a specific filename, type it here. The usual default (which maps to ~/.ssh/id_dsa) is perfectly fine for most uses, and in fact unless you have a reason for renaming the key you should leave it this way.
  • Enter passphrase (empty for no passphrase)
    Enter same passphrase again
    This is where you should enter your passphrase. To understand what this means, please see the article Passphrase. DO NOT SIMPLY PRESS ENTER!

The remainder of the output tells you the filename for the key, the public portion of the key, and the key's fingerprint - a small hash of the key itself which is slightly less unique, but easier to compare than the entire key length.

Congratulations, you have a DSA SSHv2 keypair!


RSA

RSA keys are similar to DSA keys, and will let you login with the SSHv2 protocol as well. The procedure is the same as for DSA keys, but simply changing the type specified to ssh-keygen: 

ssh-keygen -t rsa

Again, unless you know you explicitly need a RSA key, there's probably little reason to make one.


RSA1

RSA1 keys are a different beast entirely. These are only used with the older version 1 of the SSH protocol (SSHv1), which is no longer developed and has been proven less secure than SSHv2. If for some reason you know you need to connect to some place that does not support SSHv2, then you'll need to generate one of these keys. Again, as with DSA keys, the procedure is the same, just the key type to pass to ssh-keygen differs: 

ssh-keygen -t rsa1


Converting keys

If you have a key from a remote location which uses a different SSH program, or you want to send a copy of your key to someplace that doesn't use OpenSSH-compliant programs, you may need to convert your key to make it work. Due to the number of possible programs, it's difficult to explain all the choices for converting keys, however one example is converting a key to work with the ssh.com program. 

ssh-keygen -e (input file) > (output file)

Where:

  • -e: tells ssh-keygen to export a key in SECSH format
  • (input file): The key file you wish to convert; may be the public or the private key
  • (output file): The file to store the converted key

Conversely, you can use the '-i' option to ssh-keygen to convert from SECSH format to OpenSSH.

NOTE: In some cases, your private key file (if that's what you're converting) may need to be unencrypted first. See below for more details.


Changing your key's passphrase

SSH in Windows

Using SSH

Basic usage

ssh-agent

Tips & Tricks

Errors & Warnings


Advanced topics

Remember that once you setup keys, and have your ssh-agent running happily when you login, that you will need to use 'ssh-add' to add your keys to the running agent or else you will be asked for the passphrase every time! You only need to do this once per agent, so if you think they might be there use 'ssh-add -l' to list the keys. If you want to delete keys from the running agent, for example at the end of the work day, use 'ssh-add -D' to remove them.

I've found a decent introduction to SSH public key authentication which is available here: http://sial.org/howto/openssh/publickey-auth/

Retrieved from "https://docs.astro.princeton.edu/wiki/index.php?title=SSH&oldid=283"