SSH - Secure Shell
As long as SSH is made available on local machine, one can simply run SSH to logon to SLAC by providing the password. This page
is for user who needs to bypass the password so that they can run program
directly across the network.
Secure Shell (SSH) is a secure replacement for telnet, rlogin, rsh, and rcp. It uses encryption to keep information that you send over the network from being seen by others. It also uses public
and private keys to validate that the host and client machines are who they say they are.
Since SCS will disable RSH access soon, BaBar users should start switching to SSH for accessing SLAC machines.
16 Aug 2005
Related pages: [BaBar Home Page] [Computing] [Tools]
Map:
Once one installs SSH, access to SLAC with SSH is just like using telnet, one
needs to enter password as usual. The advantage of this
approach is it always pass AFS token to the server.
To bypass password checking, access SLAC machines from external sites with SSH is similar to RSH. The only difference is that one has to make the remote machine "known" to the SLAC server machine.
There are two methods to set up password bypass. (1) RSA/Host method: this method works for most users. (2) RSA/User method: for sites that has stricter access cotrol, try this method.
You may not want to use these methods if you need to access AFS disk and
your ASF token is not passed to the server due to older version of SSH
running on your site. To turn on the AFS passing, you can ask your system
manager to do one of the following: (1) patch it (the ssh 1.1.27 version) or (2) turn it on (the OpenSSH version, which requires some external AFS installation).
The RSA/Host method is recommended if one needs to bypass password checking. It uses ~/.ssh/known_hosts file to authenticate the host and uses ~/.rhosts to authenticate the user.
A. ~/.ssh/known_hosts [This step is not needed to use ssh
between two SLAC machines. See
/etc/ssh/ssh_known_hosts at SLAC]
B. ~/.rhosts [authenticate user]
In most cases, setting these two files are enough to avoid providing password interactively. In case this method does not work, try the RSA/User authentication method in the later section.
This step authenticates the client machine. Each server machine has a ~/.ssh/known_hosts file that list all the known host. To access a machine at SLAC, login to this machine with any method that works, then run 'ssh' back to the client host to set up this file.
from machine <slac-host> at SLAC
$ ssh <client-machine> date
Host key not found from the list of known hosts.
Are you sure you want to continue connecting (yes/no)?
yes
Answer 'yes' to add a host key to the ~/.ssh/know_hosts file at SLAC. Without
these host key, SSH request will be rejected.
This step authenticates the user. The ~/.rhosts file is the same as RSH's. Its format:
<host address1> <uid1>
<host address2> <uid2>
...
For example:
morgan11.slac.stanford.edu mark
shire01.slac.stanford.edu mark
[Note]: This step is optional, the default is providing the password with the keyboard.
To bypass the password prompt to facilitate commands such as importrel and importver, set up the ~/.rhosts on this SLAC machine (server). From now on the password will be bypassed when you run 'ssh' from that remote machine to the SLAC target machine.
Some sites may disable the lower range ports thus disable the RSA/Host authentication. The symptom is that even though one set up the ~/.rhost and ~/.ssh/known_hosts, he is still asked for the password. When this is
the case, one can try RSA/User authentication instead.
Within SLAC it is best to use a rsa1 key together with protocol
version 1 as this will give you AFS token forwarding. SLAC is
using a custum built ssh so token forwarding may not work with
standard clients.
Ouside of SLAC the use of ssh protocol version 2 is encouraged so you
can use rsa/dsa keys.
Protocol 1: [recommended for intra-SLAC connection via SSH]
From client [where one runs ssh]
$ ssh-keygen -t rsa1 [create public key ~/.ssh/identity.pub]
$ scp ~/.ssh/identify.pub <server>:~ [copy public key to server]
From server
$ cat ~/identity.pub >> .ssh/authorized_keys
From client
$ ssh-agent csh [start a new session with agent]
> ssh-add [add .ssh/identity to ssh-agent]
> ssh <server> date [test it]
Protocol 2: [recommended for SLAC and outside connection via SSH]
From client [where one runs ssh]
$ ssh-keygen -t rsa [create public key ~/.ssh/id_rsa.pub]
$ scp ~/.ssh/id_rsa.pub <server>:~ [copy public key to server]
From server
$ cat ~/id_rsa.pub >> .ssh/authorized_keys [append key to server]
From client
$ ssh-agent csh [start a new session with agent]
> ssh-add [add .ssh/identity to ssh-agent]
> ssh -2 <server> date [test it]
logon to client machine [where one runs ssh]
ssh-keygen -t rsa1 [create keys]
Logon to the client machine and run ssh-keygen to create pair of RSA keys. When prompted for a passphrase, select one that is hard to guess. The public key will be created in ~/.ssh/identity.pub,
the private key will be created in ~/.ssh/identity.
logon to the server machine
emacs ~/.ssh/authorized_keys [add keys]
Logon to the server machine and add the public keys from client machine's ~/.ssh/identity.pub to server machine's ~/.ssh/authorized_keys. The list of public keys stored in this file will enable
server to grant connection request from the client.
from the client machine [where one runs ssh]
ssh-agent csh [run csh under ssh-agent]
From the client machine, type ssh-agent csh to create a csh session. One can also replace 'csh' with tcsh, startx, xterm, etc. The purpose of running ssh-agent is to avoid typing the passphrase
interactively. Ssh-agent provides keys automatically.
One should then run ssh from these window/process that were spawned with
ssh-agent to take advantage of the auto-supply of the private keys. The
ssh-agent is not running as separate process, each user must create his
own window/process under his own ssh-agent.
from the client machine [where one runs ssh]
ssh-add [add .ssh/identity to agent]
From the process under ssh-agent on the client machine, type ssh-add to copy ~/.ssh/identity to ssh agent. One can also type 'ssh-add -l' to display the private keys in the agent or 'ssh-add -d
<file>' to delete keys from the agent.
Once the private key of a client machine is held by the agent, the interactive passphrase dialog will be bypassed.
Problem: AFS token is not passed over to the server.
Solution: Ask your system manager to do one of the following: (1) Normal
SSH: patch the SSH (the ssh 1.1.27 version) (2) OpenSSH: turn the AFS
passing on (the OpenSSH version, which requires some external AFS
installation).
logon to client machine [where one runs ssh]
ssh-keygen -t rsa [create keys]
Logon to the client machine and run ssh-keygen to create pair of RSA keys. When prompted for a passphrase, select one that is hard to guess. The public key will be created in ~/.ssh/id_rsa.pub,
the private key will be created in ~/.ssh/id_rsa.
logon to the server machine
emacs ~/.ssh/authorized_keys [add keys]
Logon to the server machine and add the public keys from client machine's ~/.ssh/id_rsa.pub to server machine's ~/.ssh/authorized_keys. The list of public keys stored in this file will enable
server to grant connection request from the client.
from the client machine [where one runs ssh]
ssh-agent csh [run csh under ssh-agent]
From the client machine, type ssh-agent csh to create a csh session. One can also replace 'csh' with tcsh, startx, xterm, etc. The purpose of running ssh-agent is to avoid typing the passphrase
interactively. Ssh-agent provides keys automatically.
One should then run ssh from these window/process that were spawned with
ssh-agent to take advantage of the auto-supply of the private keys. The
ssh-agent is not running as separate process, each user must create his
own window/process under his own ssh-agent.
from the client machine [where one runs ssh]
ssh-add [add .ssh/identity to agent]
From the process under ssh-agent on the client machine, type ssh-add to copy ~/.ssh/id_rsa to ssh agent. One can also type 'ssh-add -l' to display the private keys in the agent or 'ssh-add -d
<file>' to delete keys from the agent.
Once the private key of a client machine is held by the agent, the interactive passphrase dialog will be bypassed. Use 'ssh -2' to activate the SSH authentication protocol 2.
rlogin -> ssh
rsh -> ssh
logon to SLAC:
OLD: rlogin <slac-host>
NEW: ssh <slac-host>
execute a command:
OLD: rsh <slac-host> date
NEW: ssh <slac-host> date
Maintained by Terry Hung. Send suggestions and additions to
terryh@slac.stanford.edu 650-926-3618
|
