How to setup SSH keys for ISI acounts

Contents

  1. Introduction
  2. Installation
  3. Logging into an Action machine from another action Machine
  4. Logging into an Action Machine from a user administerd machine/OpenSSH

Introduction

ISI uses two types of SSH servers for their remote access. One, the open-source OpenSSH/SSL server (present on most user installed machines including jam, skynet, sunshine, etc.. ) and the commercial SecureShell version (present on all action installed machines including rachmaninov, acapella, etc.. )

Achieving proper interoperability is tricky and that is the reason for this guide's existance. This guide is only introductry material that will enable you to get SSH and Remote access working properly. It is not an advanced bible into the inner workings of the SSH protocol!.


Installation

Once you get a machine on ISI that was installed and administered by action you would need to 1) Login to that machine remotely, and 2) Login to that machine from other action administered machine. 2 is much easier than 1 and we will explain setting up 2 first.


Logging into an Action machine from another action Machine

To enable this type of access (say, from gazoo to rachmaninov) we first have to setup SecureSSH type SSHv2 keys. This is done by using ssh-keygen2 command installed in all action administered machine. the command is

 % ssh-keygen2 -tdsa -b1024 

The above command generates a 1024-bit dsa keys name id_dsa_1024_a and id_dsa_1024_a.pub in a .ssh2 directory inside your home directory. To enable access to this machine from other action adiministered machines, simply add 2 more files to your .ssh2 folder, one called authorization and the other called identification.

The authorization file should contain the following

 Key	id_dsa_1024_a.pub 

The identification file should contain the following

 IdKey	id_dsa_1024_a 

The above process needs to be done only once because, your home directory is NFS mounted and it is shared on all action administerd machines.


Logging into an Action Machine from a user administerd machine/OpenSSH

This part is slightly trickier and needs a bit more attention. It is best if you do it within ISI, or have a friend who has setup his ssh-keys already help you. This guide assumes that on user installed machines, you have password authentication access from an ISI administered machine.

First, and foremost, you need to generate SecureSSH sshv2 compatible keys from an machine that runs OpenSSH, this is done by first generating a key pair using the ssh-keygen command (with the same syntax as above) and then converting the public key to the SSHv2 format using the following command

 % ssh-keygen -e -f public_key_filename > action_public_key 

where the public_key_filename is the filename of the public key that was generated by the ssh-keygen command. The above command creates a new file called action_public_key which is compatible with SecureSSH SSHv2 servers. Now login to your ISI machine (physically) and then copy this new file from the user administerd machine to the action administered machine using the scp command. You should copy the file action_public_key to the .ssh2 folder inside your nfs mounted home-directory on the action administered machine. Then add the line

 Key	action_public_key 

to your authorization file.

Once this is done, you must be able to login from a user-administered machine (or machines that run OpenSSH, including machines on the main-campus such as aludra.usc.edu, nunki.usc.edu, etc..). However, this alone is not enough for complete interoperability. For complete interoperability, you need to be able to login to a OpenSSH/user administered machine from an action administered machine. This is done by first converting the SSHv2 keys (the id_dsa_1024_a.pub in your .ssh2 directory) to OpenSSH version keys. Most action administered machines come with OpenSSH installed, but the default ssh command redirects to the SecureSSH version. There are 2 ways of setting this up. The first is to use the default ssh client (SecureSSH v2) and convert the keys to OpenSSH format. The other is to switch your client to OpenSSH. The first method is prefferred because, this saves you the pain of setting up whatever you've done in the previous section all over again on an action administered machine.

To setup, using the first method, find out where your OpenSSH version of ssh-keygen is. (usually in /usr/bin/ssh-keygen) and then use the following command to convert your public key file to OpenSSH format :

 % /usr/bin/ssh-keygen -i -f id_dsa_1024_a.pub > open_ssh_public_key 

The above command should create a file called open_ssh_private_key, copy this file into the OpenSSH machine using the scp command (it is assumed that you have password authentication on the OpenSSH machine so you can do this). You should copy that file into the .ssh directory in your home directory in the OpenSSH machine. Once you've done that, issue the following command to append this new public key to the authorized_keys file inside your .ssh directory.

 % cat open_ssh_public_key >> authorized_keys 

Once you've done the above 2 steps, you must be able to both login from Action machines as well as user installed / openSSH machines.


The University of Southern California does not screen or control the content on this website and thus does not guarantee the accuracy, integrity, or quality of such content. All content on this website is provided by and is the sole responsibility of the person from which such content originated, and such content does not necessarily reflect the opinions of the University administration or the Board of Trustees