Status for Andrew DeFaria

Issue

Gantry mentioned that we are still having issues with pre-shared key access to various systems using pswit as the log in. This email will serve to document how pre-share key access works, how we are using it here and how the process is breaking down. We could attempt to script it but there are challenges and issues with that, specifically the gathering of ssh keys requires root access. Or we could simply learn how it works and follow a process, which I'll suggest.

How pre-shared ssh access works

In order to ssh to another machine as another user (or any user including yourself) using a pre-shared key you eed have a key to share. Therefore you need to generate an ssh key. We tend to use DSA keys as they are stronger. The process of generating an ssh key will not be discussed here but if you have one then in your home directory you'll have a file name id_dsa.pub under your .ssh directory.

The contents of this file needs to be placed into the "receiving" user's ~/.ssh/authorized_keys file. The act of doing this specifically states "I know <x> and I will allow him to ssh into this machine as me". So if I (p6258c) want to ssh to seast1 as pswit I need to get my DSA key (~p6258c/.ssh/id_dsa.pub) into pswit's authorized_keys file (~pswit/.ssh/authorized_keys).

NIS domain/Windows considerations

An additional complication here is that pswit in the RAN NIS domain != pswit in the RANTEST NIS domain. So If I wanted to be able to ssh as pswit to ranray I'd need to also get my DSA key (generated on the RAN NIS domain) into ~pswit/.ssh/authorized_keys. remember pswit's home directory on ranray != pswit's home directory on seast1. Both entities (the pswit user ID in RAN and the pswit user ID in RANTEST) are distinct and different users.

A further complication is that pswit on the 11 Windows machines are all local users to those Windows machines. The Windows machines are in the set (rantm50[1..7], sim[1..4]).

Gathering ssh keys and building a combined authorzied_keys file

So we need to collect ssh keys from multiple users, in multiple Unix NIS domains to multiple machines. In the past what I did was to gather all of the ssh keys for the users on the RAN side into an authorized_keys file named ran and then gathered all of the ssh keys for the users on the RANTEST side in an authorized_keys file named east. Normally an ssh key would say "<user>@<machine>" where <machine> is the machine which ssh-keygen was run. To avoid confusion I changed the comment at the end of each key to say "<user>@ran" or "<user>@east" in the respective files. Then I would concatenate the two files, ran and east, to one authorized keys file. This file was then checked into Clearcase under rantest_auto/config.

Dissemination

Since the home directory for pswit is always the same home directory for all machines in the RAN domain, and since the same is true in the RANTEST domain, we need only set authorized_keys twice, once in RAN and once in RANTEST, for the Unix side. However we need to also disseminate keys to 11 Windows boxes. Here's, effectively, how I do that.

$ machines="\
>  ranray\
>  seast1\
>  rantm501\
>  rantm502\
>  rantm503\
>  rantm504\
>  rantm505\
>  rantm506\
>  rantm507\
>  sim1\
>  sim2\
>  sim3\
>  sim4\
> "

$for machine in $machines; do
  scp -q authorized_keys pswit@$machine:.ssh
done

This disseminates the authorized_keys file to all the appropriate machines.

Current state

Currently, gathering up all authorized_keys files in a reverse fashion to the above, we have:

The way to have pre-shared ssh key access working the best is for each Region/Machine to have the same amount of entries (actually the exact same authorized_keys file). But we can see that people are indiscriminately changing the authorized_keys file only in certain places causing confusion and causing the process to break down.

Suggested process

When somebody reports that they are having a problem with ssh access using a pre-shared key to become pswit on another machine they should submit a help desk ticket. The way to resolve the help desk ticket is to:

1. Generate this user's DSA ssh key (if required) on both the RAN and the RANTEST NIS domains
2. Change the host name associated with the key to "ran" or "east" as appropriate
3. Open a WOR in the RANTEST_Auto project and create a view
4. Checkout the rantest_tools/config/authorized_keys file and edit it appending the two DSA ssh keys
5. Checkin and deliver the WOR
6. Either execute the above code to disseminate the new authorized_keys file or perhaps we could write a simple script to do it.
   

Comments?

Posted by at 5:25 PM | Permalink | TrackBacks (0)