new access restrictions to jlab machines

[Richard Jones <richard.t.jones@uconn.edu>]

Dear colleagues,

If you have been reading the Computer Newsletter issued periodically by 
the Jlab CC you will know that as of today they have begun to disable 
the standard connection pathways that we have been using to access 
computers on the jlab site, namely ftp and ssh to jlabs1.  From now on 
we are going to have to go through either login1.jlab.org or 
login2.jlab.org to get in from the outside. Not that these are just new 
names for jlabs1-equivalent machines;  you cannot actually do things on 
login1 or login2 other than maybe list your files.  The normal behavior 
from now on is that you first get into login1/2 and from there you do a 
second ssh connection to get to jlabs1 or whatever other host you want 
to get to.  That is the new procedure outlined in the newsletter, and I 
have found that it actually works the way they described!

Now for the bad news.  They have also disabled our familiar pathway for 
doing remote cvs access, namely the "pserver" mechanism.  If you are not 
sure what that is, just know that if you have ever used a cvs command to 
get code from/to the halld repository you will have used the cvs 
pserver. According to the newsletter, the pserver was withdrawn on March 
19 because it uses a very insecure method.  On the other hand, the new 
method proposed in the newsletter is very secure, as I can attest having 
experimented extensively and shown that it permits no access whatsoever. 
 I can think of no method more secure than that.  Part of the problem is 
a notable misprint in the newsletter and part is because of important 
missing steps.  I correct the misprint and supply the missing steps 
below.  Please follow these steps to make sure that in the future you 
will be able to continue using the cvs repository at Jlab.

1. In your home directory (under whatever account on your local machine 
you access the cvs repository) find the file ".cvspass" and delete it. 
 The new cvs method will not use the "cvs login" command.

2. Use your favorite editor to create a new file called /tmp/Root.new 
and insert a single line containing the following text

username@login1.jlab.org:/group/halld/cvsroot

where username is replaced with your own jlab userid.  Save the file and 
exit the editor.

3. Now go to the top level where you keep your cvs project directories 
and do the command

find . -name Root -exec cp /tmp/Root.new {} \;

Type the command just as shown - the backslash before the final 
semicolon is important.  Now you can delete the /tmp/Root.new file.

4. Use the regular command line ssh command to log in to this account on 
login1.jlab.org once. This is necessary to get rid of the "I don't know 
if this machine is really who it says it is." complaint from ssh the 
first time it connects to a new machine.

5. Go into your .cshrc or .tcshrc script (or wherever you are set up to 
define the CVSROOT environment variable) and replace the line where 
CVSROOT is defined with the following 2 lines:

setenv CVSROOT username@login1.jlab.org:/group/halld/cvsroot
setenv CVS_RSH ssh

where once again username should be replaced with your jlab userid. 
 Note that the :pserver: prefix is now gone from the CVSROOT definition 
and the new variable CVS_RSH has been added.  After this change log out 
and in again (or rerun the setup script) to update these definitions in 
the present working environment.

6.  Now try one of the cvs commands, such as "cvs checkout Examples" or 
something like that.  It should now prompt you for your password and 
execute the request successfully.  With the new setup you have to type 
your password again for each command.  That may not seem like a more 
secure framework to non-experts like us but hey, it works.

"But grandmother, what long passwords you have!"
"To better secure you, my dear," said the wolf.

Richard Jones