Overview
To ensure the integrity of user accounts, the College of Computing requires encrypted transmission of all credentials. We employ Secure Shell (SSH) to provide secure, remote access to our Linux-based servers. SSH supports both password- and public key-based authentication. The private key takes the place of a password. Instead of typing in a password on the keyboard, you supply a file with your key in it. Private keys are extremely hard to decrypt or guess, and there is no password for a key logger to steal. Of course, if someone obtains your private key, just like if they figure out your password, then they can gain access to any systems that you can. Your private key must be stored somewhere that no one but you will have access to it. We highly recommend that you store it on a USB key, memory card, or other removable media that you can keep with you. If you must store it somewhere that others might be able to access it, then you must encrypt it with a passphrase. Most of the programs that create private/public key pairs give you the option of encrypting it. You should encrypt your key with a long passphrase; the longer and more random, the better. If you encrypt your private key, then you will have to decrypt it by entering your passphrase before you can authenticate.
Why do we not permit clear text password services?
When using clear text passwords, anyone who is looking at the traffic between your machine and the remote server will be able to see your username and password.
How does SSH work?
SSH solves two different problems with regular TELNET: authentication and encryption.
Authentication refers to how CoC servers know that you are who you say you are. SSH allows you to login with RSA or DSA public/private key authentication. You start by generating a public/private key pair. Then, you upload a copy of your public key to a CoC server. From now on, when you try to login, the server uses your public key to send you a challenge, that only the holder of your private key (hopefully just you) can answer. While this scheme is much safer, it does have one major flaw: anyone who gets hold of your private key can login as you. Hence you must be very careful about securing your private key. Read the Why should I use a passphrase section to see one way to help protect your private key.
Below you will find instructions for generating keys, securing your private key, and setting up public key authentication with remote SSH hosts. The PuTTY and OpenSSH packages are used, because they are widely used and handle the Microsoft Windows, Linux, and Mac OSX platforms. Other packages such as SecureCRT should have similar functionality but are not described.
Encryption is the process of encoding messages or information in such a way that only authorized parties can read it. Everything you type and receive in an SSH connection is encrypted. This will prevent bad guys from seeing what you are typing or reading on the server.
What are known hosts, and why does it ask me about them?
Short answer: The first time you log into each server, you'll be asked if you want to add the host key to your known hosts. Say yes.
Longer answer: Each time you log into a server using SSH, the protocol checks the server's key (this is different from the individual user keys which you setup above). If the servers key doesn't match what your SSH client remembers (or if your client has never connected to this server before), it will ask you if you want to accept that host key.
Why? This is to verify that the server you are connecting to, is really the server you think it is. There is a class of attacks known as "man in the middle" attacks. The way they work is that someone sets up a new server, and hijacks a DNS name. Their goal is to let you login, and hope that they can then steal your password, or modify your account to do things you don't want it to do on other servers.
Luckily SSH will notice if that happens, and will tell you. So, when you are asked if you want to accept a host key, you should accept it if you've never connected to that server from this client before. But if you have connected before, then you should be suspicious. Either the server has been reinstalled and the key changed, or you are not connecting to where you think you are connecting.
Generating and using RSA Keys
Before you can use public key authentication, you need to create your public/private key pair. Protecting your private key is discussed in detail below, but the first rule is:
Never store an unencrypted private key on a network share.
When generating the key, make sure it is written to a protected location (USB key, local storage on a trusted machine, etc.). You must use a passphrase to encrypt your private key.
To generate your RSA key pair, use either of the following instructions, depending on what OS you are using:
Using SecureCRT (Windows, Mac or Linux)
Instructions for using SecureCRT can be found here.
On a Mac using ssh-keygen (*nix, OSX, command line)
Open the Mac OSX terminal:
- From the finder, click on the Go menu
- Click Utilities
- Double-Click Terminal
Use the following commands to generate your private/public key pair:$ ssh-keygen -t rsa -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/net/hp48/username/.ssh/id_rsa:/media/keyfob/id_rsa4096)
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /media/keyfob/id_rsa4096.
Your public key has been saved in /media/keyfob/id_rsa4096.pub.
The key fingerprint is:
a6:f0:0b:7a:cb:1c:39:c4:b9:9a:33:e8:3a:fa:58:ac someone@foobar
$
Adding your private key to your OSX keychain
From the OSX Terminal, type in:ssh-add -K /path/of/private/key(e.x. ssh-add -K /media/keyfob/id_rsa4096)
PuTTYgen (Windows)
PuTTYgen is an open source product that is part of the PuTTY project. You can download a Microsoft Windows binary here. It is a standalone executable, so you can just save it anywhere. When you execute it, you will see the following screen:
Update the number of bits to 4096, and then click 'Generate'. On the next screen, you will need to move the mouse around the window to generate some entropy:
Then wait as the key is generated:
The final window looks like this:
Update the key comment appropriately (indicate the username and host that you will be connecting from). Then highlight the key in the text box, and copy it into a file named id_rsa4096.pub or similar. You can also click the 'Save public key' button to save a version of the public key that Pageant (see below) can use. Finally, enter a passphrase if you wish to encrypt the key, and click 'Save private key'. Save the key somewhere safe. If you do not type in a passphrase, you will be prompted with the following warning:
A note on passphrases
If you leave the passphrase blank, then the key will be created unencrypted. Unencrypted keys must be closely protected (i.e., usb key kept on your person). If you set a passphrase, then you will need to provide the passphrase each time you authenticate using the key. A passphrase is generally much longer than a password. See the Passphrase FAQ for more information.
Securing Your Key
The private key is your secret key. If an adversary obtains your private key, they can masquerade as you in any systems that trust you using that key. Ideally, you should store your encrypted private key on some media that you never let out of your sight. Whenever you need to authenticate, you produce the private key and type in the passphrase. If you have to authenticate often, then that can be too much of a burden. For SSH authentication, an agent is the solution to providing a reasonable level of security for your private key while not requiring you to produce the key and type in the passphrase for every authentication.
An authentication agent will cache your private key, and provide it for you to multiple login sessions.
ssh-agent, ssh-add (Unix)
ssh-agent is a part of the OpenSSH package. Its usage is rather advanced, so only two use cases will be described here. The first is a trivial case: in Redhat Enterprise Linux, ssh-agent is started automatically when you log into the graphical environment (gdm). The second case is if you need an agent on the command line:
% ssh-agent -t 14400 $SHELL
%
The -t 14400 specifies that the agent should remove keys after 4 hours. Ideally, you should clear out your keys whenever you are done connecting to remote hosts, but in case you forget, the time limit will take care of it. After the agent is started, you can add your private key to the agent with ssh-add:
% ssh-add /media/keyfob/id_rsa4096
Enter passphrase for /media/keyfob/id_rsa4096:
Identity added: /media/keyfob/id_rsa4096 (/media/keyfob/id_rsa4096)
%
If your key is unencrypted, then you will not be prompted to enter a passphrase.
Pageant (Windows)
Pageant is an authentication agent from the PuTTY software suite. You can download a Microsoft Windows binary [here]. When you execute the standalone binary, an icon appears in the systray:
Right click on the icon and select "Add Key":
Select the private key you saved above, and enter the passphrase if you set one:
Until you remove the key from Pageant or logout/reboot, you will be able to use PuTTY to connect to any remote hosts that are configured to trust your private key.
Configuring Remote Servers
For each host that you would like to log into using public key authentication, you need to configure SSH with your public key. For hosts with OpenSSH servers (all of the CoC unix servers use OpenSSH), the file ~/.ssh/authorized_keys is where you put the public keys corresponding to all the private keys that you want to grant access. There are various ways that you can get the public key into the authorized_keys file. You can open up the authorized_keys file with a text editor and copy/paste the public key string into the file. The public key looks like (I added line breaks, but it should all be one line!):
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAgEAtsa8oz6tVypdbUvLA+rGoHz6Wbwmc1NnMA+gd+fPXdFyfqYu/rf6ITaTWObwgjmIhUJ
gzKR+ASPJCQX3WZnwRrgrsWkq/XPG9TdFXySkH8TqHHhxsKTGcZxhIgYdgFp70Vg5zvakD5xCMaXU4v6hsQ66KajSAPLUQdPZFMkW9V
7iebovMLO+aZY/sjHm70v5OoRXvp/LGVTGELk0/sv6GB5uT/o8dIjHg5kBAS7iMd2yQOX714T7U73ENsm2RJJ9s/W/4Wg9e0q0ABfNp
cypTyb5NcCHjpVERGF8QcxSFxbymKeLiae/9UHVcgIPbm43y+/mDdxDPW5RS4nXeb665CLsStuTygJJjJJIaTOXpWJzCqMyNgGWc9Og
fIoQNPokJAYS9iUJk6R0sCgvvGcX/yWkAaV8/vRTFWyWhBoqJAWz7v7Fhc6xUhVfobfcg8gfUntJeA3IK0f0fjcotUtsmYifm/zw3A7
T6621eNqBmJGA98UYMG/sPht7aZWEuDz9pDtVKAde5srieqYXJJz7CbWL9oz0ieyIdd9JmcNADmEi8qPHMyToaTC5rm9tcPKNrxOMLl
f+ySEd3ZF/kRqIR2uNlylASRncIqvB9U/f1irGkjSJ6AKMAbTC3bc0D8nfkOow8/873WaZQz9DoHiwCiIe9QlXq2qXp1KePj6tZc0=
foo@foobar
An alternative way to add a key to the authorized_keys file is to use WinSCP or similar program to scp the file to the remote host and then concatenate it:
% cat ~/id_rsa4096.pub >> ~/.ssh/authorized_keys
% chmod 600 ~/.ssh/authorized_keys
%
That's it! When you connect to the remote host, you will be using public key authentication. If it prompts you for a password, then something is wrong; go back and double-check all the steps carefully.
How to run a single command on a remote CoC Unix server
Simply type:
SSH hostname who
Note: This just automatically works once SSH has been setup correctly.
How to copy files from one CoC Unix server to another
There are 2 possibilities with SSH:
- sftp
- scp
scp
The syntax to copy a file from killerbee1 (for example) is:
scp foo@killerbee1:filename .
This would copy the file "filename" on foo's killerbee1 account to the current directory on your CoC server. (NOTE: There is a space period at the end of that command that are very important.).
scp filename foo@killerbee1:Mail
This would copy the file named "filename" on your CoC account, to the directory "Mail" on foo's killerbee1 account.
NOTE:This will work regardless of whether you have SSH keys set up for connects between killerbee1 and CoC or not. If you do not have it setup, this will prompt you for your killerbee1 password. Click here for info on how to set up keys to save you from having to enter your password.
sftp
sftp works very simular to regular ftp. The main difference is that sftp assumes your username is the same on the client machine and on the server (Note: This is almost certainly an invalid assumption when you ftp to or from killerbee1).
The correct syntax is:
sftp user@server
For example,
sftp foo@killerbee1
From there, it behaves just like ftp.