to return to start of pageClick on
to return to start of page
SSH uses for
identification a private/public key pair. The key pair is generated on the
client (your local machine), and the public key is then copied to the host (the
remote server at SLAC). For detailed information on ssh and ssh-keygen see http://www.slac.stanford.edu/comp/unix/ssh.html
and the ssh and ssh-keygen man pages at SLAC.
Getting Started
For Windows machine follow the Windows Instructions.
For Unix machines follow the Unix instructions.
If after setting up ssh, you are having problems, see the TroubleShooting section at the bottom of this page.
Log
on to any public SLAC Unix machine
such as
centaurusA.slac.stanford.edu
This is the remote machine.
Setup the .ssh directory on the remote
machine, if necessary.
On the remote SLAC machine, you may already have a directory $HOME/.ssh with
subdirectory '.public' and soft
links pointing to files in .public. Only some of these files may exist
already.
If the $HOME/.ssh directory and
its subdirectory and soft links do not yet exist, do:
Accept
the proposed location for the file 'identity'. It will ask for a
pass-phrase, give the empty one (i.e. just hit <CR>).
Here is an explanation
from Tony Waite on what is happening with the use of RSA encryption and blank
pass-phrases.
Important:
make sure that the '.ssh' directory and the files 'authorized_keys' and
'authorized_keys2' are not writable by any but the owner:
>
chmod go-w <file_or_dir>
Next
you must append the identity.pub file to your authorized_keys so that
your public key will be recognized when you attempt to connect from your
local machine:
cat
identity.pub >> authorized_keys
Get the ssh executable.
You can get the distribution
(ssh-1-2.14-win32bin.zip) from:
ftp://ftp.slac.stanford.edu/groups/glast/ground/WindowsThings.
The
presently distributed version of ssh uses protocol 1.4, which means that you
are limited to SSH1.
Note: an ssh terminal emulation package
will not suffice! Get the distribution listed above!
Install the ssh client on your Windows machine.
To do this you should extract
the client-archive to whatever location you want, e.g. C:\PROGRAM1\SSH.
Set the environment variables on your Windows machine.
SSH needs the environment variable HOME, which defines the directory in which the subdirectory .ssh is located. This directory will hold the key pair for identification of the client
The environment variable PATH has to be updated to contain the path to the directory in which the ssh executable is located
To set both environment variables
Windows
2000 / XP
open Start -->
Settings --> Control Panel --> System
choose Advanced
--> Environment Variables
Windows
NT
open
Start->Settings->Control Panel->System->Environment
Get
the identity key
To
get the key we will cheat a bit. We do not run the ssh-keygen procedure,
but 'copy' a private key, which already exists on your remote Unix client.
To
copy a file from an external client to a SLAC host you have to use
'scp' (secure copy) or 'ftp' from the SLAC machine to the external
machine. Due to the SLAC firewall, ftp to SLAC is not possible.
Create the directory '.ssh' on your Windows machine using DOS. It is necessary to use a DOS window due to the . (dot) in the directory name.
Transfer using scp or ftp with mode bin the file 'identity' from the remove Unix machine on which you have established the ssh key-pair before.
Set
directory '.ssh' and the file 'identity' Read-only
(right click on file,
choose Properties --> pane
General, set Attribute 'Read-only')
Get
the file of known SLAC hosts
A
file which contains the keys for all public SLAC
Unix machines is available through anonymous ftp from the server
ftp.slac.stanford.edu, in the directory /admin/known_hosts.
Copy this file to .ssh/known_hosts
on your local client. You may need to take care to merge this with other
known hosts, which you already have in this file and you want to
retain.
Test
that ssh is working
In
a DOS window
Verify
the Logon to the host
You should now be able to logon to the remote
machine without getting warnings. You will still be asked for a password
(I guess this is to get an afs token). In case of problems
try the verbose mode (-v) and/or give your userid -l on the remote
machine.
If your user name on the remote machine is different than your user name
on your local machine, you will need to use the -l flag to specify your
user name on the remove machine.
>
ssh
-v
-l
<userid>
centaurusa.slac.stanford.edu
Execute
a command on remote host.
The following command should not require a password,
but simply execute the command on the remote machine. Commands requiring
an afs token will, however, not work.
If your user name on the remote
machine is different than your user name on your local machine, you will
need to use the -l flag to specify your user name on the remove machine.
>
ssh centaurusa.slac.stanford.edu date
This
should result in something like:
Thu Aug 1 09:09:50 PDT 2002
You should not be prompted for a
password - if you are there is something wrong with the SSH setup.
These are pretty much the complete set of instructions for what you have to do to set up ssh on Windows. If you still have problems then you can check out the Win CVS faq entry.
First you should determine what
version of ssh is running on your local machine. You can do th this by
issuing the command:
>
ssh -V
Follow the instructions for your version of SSH 1 or 2.
Log
on to any public SLAC Unix machine,
such as centaurusA.slac.stanford.edu
This is the remote machine.
Run ssh-keygen, if necessary, to
produce the .ssh directory on the remote machine.
On the remote SLAC machine, you may already have a directory $HOME/.ssh with
subdirectory '.public' and soft
links pointing to files in .public. Only some of these files may exist
already.
If the $HOME/.ssh directory and
its subdirectory and soft links do not yet exist, execute the
following if you have SSH 1 on your local machine:
OR
if you have SSH 2 on your local machine:
> ssh-keygen -t rsa
Accept
the proposed location for the file 'identity'. It will ask for a
pass-phrase, give the empty one (i.e. just hit <CR>).
Here is an explanation
from Tony Waite on what is happening with the use of RSA encryption and blank
pass-phrases.
Important:
make sure that the '.ssh' directory and the files 'authorized_keys' and
'authorized_keys2' are not writable by any but the owner:
issue the command
>
chmod go-w <file_or_dir>
Create the private/public key pair on your local machine and copy the public key to the remote machine.
If using SSH 1 on your local machine
Execute
the command
>
ssh-keygen -t
rsa1
Accept
the proposed location for the file 'identity'. It will ask for a
pass-phrase,
give
the empty one (i.e. just hit <CR>).
This results in the files in $HOME/.ssh
identity -
the
private key
identity.pub - the public key
Transfer
the file identity.pub to the remote machine, either using scp
(secure copy, if available), or ftp from a SLAC machine to your
client (use bin mode).
To
copy a file from an external client to a SLAC host you have to use
'scp' (secure copy) or 'ftp' from the SLAC machine to the
external machine. Due to the SLAC firewall, ftp to SLAC is not
possible.
On
the remote SLAC machine 'add' identity.pub to the file $HOME/.ssh/.public/authorized_keys, i.e.
>
cat identity.pub >> authorized_keys
If using SSH 2 on your local machine
If files do no yet exist in .ssh/public,
create them as empty files
> touch authorized_keys
Execute
on the local machine the command
>
ssh-keygen -t
rsa
Transfer the file .public/id_rsa.pub to the remote machine, either using scp, or ftp from a SLAC machine to your local machine (use bin mode).
On
the remote SLAC machine 'add' id_rsa.pub to the file
$HOME/.ssh/.public/authorized_keys2, i.e
>
cat id_rsa.pub >> authorized_keys2
Check
the permissions on the .ssh files on your local machine.
After finishing step 3 make sure that the '.ssh' directory and the files
authorized_keys' and 'authorized_keys2' on your local machine are not
writable by anyone but the owner by issuing the command
>
chmod go-w <file_or_dir>
Setup file .ssh/config on your local machine
Copy the file /etc/ssh/ssh_config to $HOME/.ssh/config
Edit the config file and add the
following lines (# starts a comment line):
Host
*
#
Host
centaurusa.slac.stanford.edu
[restricting to one machine]
ForwardAgent no
ForwardX11 no
FallBackToRsh no
Protocol 1
Get
the file of known hosts
A
file which contains the keys for all public SLAC
Unix machines is available through anonymous ftp from the server
ftp.slac.stanford.edu, in the directory /admin/known_hosts.
Copy this file to ~/.ssh/known_hosts
on your local client. You may need to take care to merge this with other
known hosts, which you already have in this file and you want to
retain.
Test to see that ssh is working correctly.
Verify
the Logon to the remote host
You should now be able to logon to the remote
machine without getting warnings. You will still be asked for a password
(I guess this is to get an afs token). In case of problems
try the verbose mode (-v) and/or give your userid -l on the remote
machine.
If your user name on the remote machine is
different than your user name on your local machine, you will need to
use the -l flag to specify your user name on the remove machine.
>
ssh -v
-l <userid>
centaurusa.slac.stanford.edu
Execute
a command on remote host.
The
following command should not require a password, but simply execute the
command on the remote machine. Commands requiring an afs token will,
however, not work.
If your user name on the remote
machine is different than your user name on your local machine, you will
need to use the -l flag to specify your user name on the remove machine.
>
ssh centaurusa.slac.stanford.edu date
This
should result in something like:
Thu Aug 1 09:09:50 PDT 2002
You should not be prompted for a
password - if you are there is something wrong with the SSH setup.
Note: People working in Europe may have to use ssf. This does not seem to cause any problems. Just replace 'ssh' with 'ssf' throughout the instructions.
If you get strange delays, and error message about "unable
to lock Xauthority file" you need to disable X11 forwarding for protocol 2.
This can be done on the command line with the -x flag, or in the ~/.ssh/config
file.
Change the line "ForwardX11 yes" to "ForwardX11 no".
Last Modified January 21, 2003
Back to Main Menu Previous Step Next Step