" /> Status for Andrew DeFaria: July 29, 2007 - August 4, 2007 Archives

« July 22, 2007 - July 28, 2007 | Main | August 5, 2007 - August 11, 2007 »

August 3, 2007

ssh

  • Helped Aaron with ssh

Adding ssh actions to CDE

Secure SHell or ssh is a more modern and secure way to access a remote system. You can add ssh actions to CDE by doing the following:

Add the following to ~/.dt/types:

ACTION Ssh
{
  LABEL           Secure shell
  ICON            Dtterm
  ARG_COUNT       0
  TYPE            COMMAND
  WINDOW_TYPE     NO_STDIO
  EXEC_STRING     ksh -c 'export _title="%"Starbase?"%";	  \
    /usr/dt/bin/dtterm -name $_title                              \
    -title "Opening hailing frequencies to starbase $_title..."   \
    -e ksh -c "ssh $_title; sleep 5;";'
  DESCRIPTION     The Secure shell action prompts the user for    \
                  the name of a system, opens a dtterm terminal   \
                  emulator window, and then performs an ssh to    \
                  that system.
}

ACTION SshUser
{
  LABEL           Secure shell
  ICON            Dtterm
  ARG_COUNT       0
  TYPE            COMMAND
  WINDOW_TYPE     NO_STDIO
  EXEC_STRING     ksh -c 'export _title="%"Starbase?"%";          \
    export _user="%"Username"%";                                  \
    /usr/dt/bin/dtterm -name $_title                              \
    -title                                                        \
      "Opening hailing frequencies to starbase $_user@$_title..." \
    -e ksh -c "ssh $_user@$_title; sleep 5;";'
  DESCRIPTION     The Secure shell action prompts the user for    \
                  the name of a system and a username and opens   \
                  a dtterm terminal emulator window, and then     \
                  performs an ssh to that system.
}

Then invoke the actions with:

$ dtaction Ssh
$ dtaction SshUser

or better yet put it into your Dtwm menus like:

    Menu Terminals
    {
      "Terminals"           f.title
      "Terminal"            f.action Dtterm
      "Remote Terminal"     f.action Ssh
      "Remote Terminal (user)"      f.action SshUser
      "X Terminal"          f.action Xterm
    }

Configuring ssh for passwordless but secure public key authentication

In order to do public key authentication you need to first generate a public key. You do this for ssh with ssh-keygen:

$ ssh-keygen -t rsa

Note you can also do -t dsa. There are RSA keys and DSA keys. I forget what the prompts are, something about a passphrase, etc. Enter no passphrase.

This should create a directory ~/.ssh with files in it. For example:

$ ssh-keygen -t rsa
Enter file in which to save the key(/home/p6258c/.ssh/id_rsa):
Generating public/private rsa key pair.
Enter passphrase(empty for no passphrase): 
$ ls -l ~/.ssh
total 32
-rw-------    1 p6258c   ccusers       226 Jun 15 13:28 authorized_keys
-rw-------    1 p6258c   ccusers       887 Jun 15 13:27 id_rsa
-rw-rw-r--    1 p6258c   ccusers       226 Jun 15 13:27 id_rsa.pub
-rw-r--r--    1 p6258c   ccusers      4082 Jul 31 15:05 known_hosts
$ ls -ld .
drwxr-xr-x   43 p6258c   ccusers      2048 Aug  3 10:28 ./
$

Then the task is to get the ~/.ssh/id_rsa.pub key added to the authorized_keys file (creating it if you need to). Here in GD that is easy. Siimply:

$ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

Now, since all GD machines in the RAN subnet share your same home directory (automounted from the same common location) viola! You now have passwordless ssh access using public key authentication through the RAN (note this does not cross from RAN -> GD network due to firewall issues). Whenever you ssh to a new machine it will bother you about adding it to the known_hosts file but after that it should not prompt again.

Also note that if this were a different situation you'd have to get the contents of ~/.ssh/id_rsa.pub over to the remote machine. For example, I could generate my keys as described above then email the ~/.ssh/id_rsa.pub from here to my home Linux system, append it to my ~/.ssh/authorized_keys on my home Linux system then I could ssh from here to home. Normally I configure my house to only allow public key authenticated logins from the outside world. I can't do it here from GD because the firewall prohibits it (which is odd)!

Final note: Sometimes, if ssh is configured to by strict about permissions, you need to change your home directory to be 755 as shown above. Normally I'm a sharing kinda guy so I have my home directory set to 775 but with ssh strict permissions that'll cause passwordless ssh to not work anymore.

August 1, 2007

ranlin0[2|3] released

  • After resolving issue with cleartrig and fonts, released ranlin0[2|3] to production

New Linux workstations ranlin02 & 03 now ready

The new Linux workstations ranlin02 and ranlin03 are now ready for use. Clearcase and Clearquest have been installed on them and they have been properly configured into the RAN network.

There is a slight issue regarding problems with Clearquest and clearprompt (a dialog box tool used by our tools) and fonts. Sometimes this leads to dialog boxes that lack any text due to font rendering problems.

A fix had been implemented. For users who will be using these new Linux boxes (especially if they use Solaris desktops, will be remotely logging into these Linux boxes and displaying things back to their Solaris boxes running CDE) simply add the following "source" to their ~/.cshrc:

#ident  "@(#)local.cshrc        1.2     00/05/01 SMI"
umask 002
set path=(/bin /usr/bin /usr/ucb /etc /usr/sbin /usr/atria/etc
/usr/atria/bin /usr/openwin/bin /usr/dt/bin /usr/local/bin
/opt/hpnpl/bin .)
if ( $?prompt ) then
   set history=64              # previous commands to remember.
   set savehist=64             # number to save across sessions.
   setenv system `hostname`     # set hostname
   set prompt="[$system`pwd`] " # set prompt
   alias       cd      'cd \!*; set prompt="[$system`pwd`] "'
endif
alias ct /usr/atria/bin/cleartool
alias ll 'ls -l'
alias la 'ls -a'
alias cdd 'cd ..'
alias cddd 'cd ../..'
#alias shello /vobs/cello/civ/test_utilities/scripts/shello
source /prj/muosran/config/.cshrc.muosran
source /prj/muosran/config/.cshrc.linux

July 31, 2007

CC/CQ on Linux

  • Fixed problem with cleartrig for the Linux clients
  • Investigated and found a work around to font problems between Linux and Sun
  • Met with development/test teams regarding documentation visibility. Also worked out the differences in the documents between builds 1, 2 and 3

    Cleartrig and font problems on Linux clients

    I hit a few problems when attempting to verify proper execution of Clearcase/Clearquest and our WOR integration on Linux machines.

    Cleartrig problems

    The first problem was that the Linux installation of Cleartrig (remotely accessible through /cleartrib/bin) was missing execute permissions for group and other. The solution to this was to add execute permissions.

    Font Problems

    his is running under the assumption that:

    1. The user is on a Solaris box and running CDE and
    2. The user is remotely logged into a Linux box (currently only ranlin02 and ranlin03) and displaying back to his/her Solaris machine

    The user may see dialog boxes with no text or other errors relating to fonts. Since most engineers use Solaris and CDE many X Font Resources are set to fonts only available on CDE supported systems1. For example, executing xrdb -q | grep -i font may result in the following:

    *Font:             -dt-interface user-medium-r-normal-s*-*-*-*-*-*-*-*-*
    *FontList:         -dt-interface user-medium-r-normal-s*-*-*-*-*-*-*-*-*
    *labelFontList:    -dt-interface user-medium-r-normal-s*-*-*-*-*-*-*-*-*
    ...
    

    Needless to say these "dt" fonts are not known in the Linux world and this causes Clearcase/Clearquest some problems when running remotely displayed to an X server using such font. The solution is to use more universally acceptable fonts such as fixed. The following set of X Font Resources seems to work:

    *Font:                  fixed
    *FontList:              fixed
    *labelFontList:         fixed
    *buttonFontList:        fixed
    *textFontList:          fixed
    *DtEditor*textFontList: fixed
    *systemFont:            fixed
    *XmText*FontList:       fixed
    *FontSet:               fixed
    *XmTextField*FontList:  fixed
    *fontGroup:             Courier
    

    If you are experiencing problems with X Fonts when running from a Linux machine add the above lines to a file, say ~/.fonts then do

    $ xrdb -m ~/.fonts
    

    Notes:

    1. These "dt" fonts are often set into CDE's environment when say using the Style Manager to change your font settings.