|
The secure shell is a secure replacement for the rsh/rlogin/rcp set of programs. It's main features are:
Details can be found in the man pages for ssh and sshd. JLab CUE Unix machines use the ssh suite of tools from OpenSSH.
The remainder of this document assumes you are using a CUE system. Most of the instructions will also be applicable to non-CUE systems though if you have installed SSH yourself the paths to the commands may need to be changed to work on your local system. To begin using the new SSH, simply make sure that the /apps/bin directory is first in your path.
Secure Shell (ssh) is available on all Common Unix Environment (CUE) and CAD sytems at JLAB.
The following sections hope to provide enough information to setup
a user
new to ssh with the appropriate files necessary for accessing
remote
hosts in a secure manner. Your login name is referred to as username.
SSH employs public key cryptography to protect your login sessions as they traverse the network. Public key cryptography uses a public key to encrypt data and a private key to decrypt it. The name public key comes from the fact that you can make that key public without compromising the secrecy of the encryption system. In fact, that's how one normally uses public key cryptography.
What this means is that it is safe to send your public key in electronic mail or by other means e.g. to have a system administrator of a remote site install that key into your account so that you can log in with it. For anyone to actually gain access they need the corresponding private key to identify themselves.
To further protect your private key you should enter a passphrase to encrypt the key when it is stored in the filesystem. This will prevent people from using it even if the gain access to your files.
The very first step is to use the ssh-keygen command to create a pair of keys for yourself. Because your private key is so important (and because it is stored on a filesystem shared by other users), you should take advantage of SSH's ability to encrypt your private key using a passphrase. This will prevent anyone who can read your private key file from being able to log in as you without a password. Since they will not know your passphrase, they will not be able to unlock your private key and use it to log in. Passphrases are similar to the passwords you already use to log in to your desktop system, though usually they are longer than a single word. The ssh-keygen command will prompt you to set a passphrase on your new key when you create it.
Always type in a good pass-phrase when prompted for one. It can be multiple words (i.e. spaces are just fine within the phrase), so you could choose a sentence that you can remember. Changing some of the words by misspelling them or by changing some of the letters into digits is highly recommended to increase the strength of your pass phrase.
Here is a sample session, your input is in bold. Note that the pass-phrase is not echoed back as you type it.
jlabl1> ssh-keygen -t dsaNotice the names of your new private key (/home/username/.ssh/id_dsa) and your new public key (/home/username/.ssh/id_dsa.pub). These are the default names chosen by SSH, and you'll need to know them later when you customize your configuration.
Generating public/private dsa key pair.
Enter file in which to save the key (/home/jdoe/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):<YOUR PASSPHRASE HERE>
Enter same passphrase again:<YOUR PASSPHRASE HERE>
Your identification has been saved in /home/jdoe/.ssh/id_dsa.
Your public key has been saved in /home/jdoe/.ssh/id_dsa.pub.
The key fingerprint is:
30:82:ab:43:e9:11:cb:7e:d6:b1:83:93:62:3e:ee:da jdoe@jlabl1.jlab.org
If you have multiple accounts you might want to create a separate key for each of them rather than having them all share the same key. For example, you could have separate keys for
This would allow you to limit access between these organizations, e.g. not allowing your university account to access your ISP account or the machines in the office. This enhances the overall security in the case any of your authentication keys are compromised for some reason.
You can change the pass-phrase at any time by using the -p option of ssh-keygen.
jlabl1> ssh-keygen -p -t dsa
Enter file in which the key is (/home/jdoe/.ssh/id_dsa):<ENTER>
Enter old passphrase:<YOUR OLD PASSPHRASE>
Key has comment '/home/jdoe/.ssh/id_dsa'
Enter new passphrase (empty for no passphrase):<YOUR NEW PASSPHRASE>
Enter same passphrase again:<YOUR NEW PASSPHRASE>
Your identification has been saved with the new passphrase.
To allow access to a system for a given identity, you'll need to place your public key in your ~/.ssh/authorized_keys file on that system. All keys listed in that file are allowed access to log in to your account. On CUE systems which mount your NFS home directory, placing your private key there once will allow you to have access to all other CUE systems.
jlabl1> cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
You could now also copy the ~/.ssh/authorized_keys file to other systems which do not share your NFS home directory if you want to log into them from your CUE account.
To establish an interactive connection to a remote system you would use the ssh command. The only parameter is the name of the remote system. The pass-phrase is not echoed back to you when you type it.
jlabs1> ssh jlabs2 Enter passphrase for key '/home/username/.ssh/id_dsa': [Enter your pass-phrase here] Last login: Thu Jun 20 22:05:46 2002 from jlabs1.jlab.orgNotice that instead of a simple password prompt, you are now asked for your key's passphrase. That's how you can tell you used your key to login. Of course, if you're going to be prompted for a passphrase anyway, why not just use a plain old password and not bother establishing keys? One reason is that using a key allows you to avoid having to type the passphrase every time you login if you do just a little extra configuration. You can avoid the pass-phrase prompts by keeping the authentication keys in memory.
If your account name on the remote system differs from the one on the local system (the system you are connecting from) you can use the -l switch to specify the remote account name.
jlabs1> ssh -l newusername jlabs2 Enter passphrase for key '/home/username/.ssh/id_dsa': [Enter your pass-phrase here] Last login: Thu Jun 20 22:05:46 2002 from jlabs1.jlab.org
You can change the default remote account name for a host by
creating
a configuration file entry for that machine.
When logging in to a remote host, SSH tries to ensure that the host you
connected
to is actually the host you requested. It authenticates the
remote
host the same way it authenticates you when you're using a key.
Each
host also has a public and a private key, and the SSH client keeps a
database
of host public keys it knows about so that it can use them to verify
that
the host is who it says it is when you're logging in. The first
time
you use the client to log in to a host, you may not yet have that
system's
public key in your database. If so, you will see a message like
the
following:
jlabs1> ssh jlabs2 The authenticity of host 'jlabs2 (129.57.35.235)' can't be established. RSA key fingerprint is 4f:c3:18:96:2a:d8:a3:e6:9c:64:d4:62:18:53:4b:31. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'jlabs2,129.57.35.235' (RSA) to the list of known hosts. Enter passphrase for key '/home/username/.ssh/id_dsa': [Enter your pass-phrase here] Last login: Thu Jun 20 22:05:46 2002 from jlabs1.jlab.org
After answering "yes", you can proceed to login normally. You
should only see this message the first time you ever log into a host
with
the new client software. If you see this message from a host
you've
already logged into before, the host's key may have changed. Since the
Computer
Center, as a rule, does not change host keys, this may indicate a
problem.
Please notify the Computer Center if you ever encounter this
situation.
If you frequently open connections to remote systems you can run your session under the ssh-agent. The agent will provide decrypted authentication keys to all the SSH clients when you create new connections. Using the SSH agent will allow you to avoid having to type your passphrase each time you log in to a system. Instead, you'll type your passphrase once when you authenticate to the agent, and the agent will authenticate you to remote systems when you log in.
Linux users should refer to this page for instructions on using the SSH agent. HP-UX and Solaris users can look here.
The ssh command can also be used to run commands on remote systems without logging in to them. The output of the command is displayed and control returns to the local system. Here is an example which will display all the users logged in on the remote system. These examples don't prompt for a password or a passphrase, so you can assume they're done using the SSH agent.
jlabs1> ssh jlabh1 who davidj ttyp8 Oct 17 20:42
todds ttyp9 Oct 18 12:37
jlabs1>
If you are using the X Window System you can use this capability to start a terminal window to start an interactive session on the remote system.
jlabs1> ssh -n hrothgar xterm & [1] 15866 jlabs1>
Use the -n to avoid the remote system from trying to read from the terminal starting the xterm and put the process in the background. A new window from the remote system should appear shortly on your display.
You can copy files from the local system to a remote system or vice versa, or even between two remote systems using the scp command. To specify a file on a remote system simply prefix it with the name of the remote host followed by a colon.
If you leave off the filename of the copy or specify a directory only the name of the source file will be used. An easy way of retrieving a copy of a remote file into the current directory while keeping the name of the source file is to use a single dot as the destination.
jlabs1> scp -p jlabs2:aliases .
jdoe@jlabs2’s password: <Type password here>
aliases 100% 12KB 0.0KB/s 00:00
jlabs1>
The -p option is not required. It indicates that the modification and access times as well as modes of the source file should be preserved on the copy. This is usually desirable.
You can copy several files in a single command if the destination is a directory.
jlabs1> scp -p jlabs2:.login jlabs2:.logout /home/jdoe
jdoe@jlabs2’s password: <Type password here>
.login 100% 2KB 0.0KB/s 00:00
jdoe@jlabs2’s password: <Type password here>
.logout 100% 1KB 0.0KB/s 00:00
jlabs1>
Using the -r ("recursive") option, you can copy entire
directory
trees with scp.
jlabs1> scp -rp ~/Documents remote_host:.
Relative filenames resolve differently on the local system than on the remote system. On the local system the current directory is assumed (as usual with all commands). On the remote system the command runs in the home directory! Thus relative filenames will be relative to the home directory of the remote account.
NOTE: When you specify remote machines in both the source and the destination the connection to copy the files is made directly between those hosts. The files are not copied through the local system. Sometimes this makes a difference in a firewalled or otherwise restricted environment.
If you're not happy with the way the SSH client behaves, you can set some configuration parameters in your ~/.ssh/config file. The ~/.ssh/config file consists of option - value pairs on each line. Here are some examples:
Ciphers blowfish-cbcThis will force your client (i.e. ssh program) to try to connect with the server using using the "blowfish" encryption algorithm.
StrictHostKeyChecking noThis will allow your client to make a connection to a server that has a different host key then the last time you connected to it. This should only be used by users that know they will be connecting to hosts that have different keys each time you login (such as a computer lab that uses one name for a pool of computers).
For a complete list of options please refer to the ssh manual page.
| File name | Purpose |
| id_dsa | Your SSH V2 private key. |
| id_dsa.pub | The SSH V2 public key that goes with your private key. This is the file you will need to distribute to remote hosts in order to log in without a password. |
| known_hosts | A list of the all the host keys from each machine you have ever logged into. |
| random_seed | Random data used by the encryption process to initialize ("seed") the algorithm's parameters with unpredictable values. |
The Jlab OpenSSH server uses the following files in the ~/.ssh directory.
| File name | Purpose |
| authorized_keys | This file contains a list of public keys that are allowed to access this account without typing a password. You will need to put your public key (id_dsa.pub) into this file. |
This document is maintained by {helpdesk@jlab.org}
Copyright Jefferson Lab 2007