Here an example command:

$ ssh "ls -l /var/nds/dib/*.TAO"

You do have to be in as ndsuser, as the SSH configuration is unique for each shell account.

Here are the notes made to set this up on another host:

# Setting up password-less SSH access (Servers running OpenSSH -- EMR standard)
ssh-keygen -t rsa	## only have to do this once

# Repeat these steps on each remote system
scp ~/.ssh/

# Run these commands in the remote shell
if [ ! -d ./.ssh ]; then mkdir ./.ssh; fi
cat >> .ssh/authorized_keys

We worked with a client that was using F-Secure#

Here is what we did there.
# Setting up password-less SSH access (For servers running F-Secure -- rare these days)
# Convert the original OpenSSH key to v2
ssh-keygen -ef ~/.ssh/ > ~/.ssh/
scp ~/.ssh/
mv ./ ./.ssh2/
echo "Key">>./.ssh2/authorization

Authentication Keys#

SSH authentication keys are data that allow an ssh server running on a remote computer to verify that you are who you claim to be. The following sections show you how to generate keys on your local machine and how to install them on remote machines.

Generating Keys#

We will generate three key pairs (each pair consists of a public key and a private key). One to support the old SSH1 protocol still in use by some facilities. And two others that can be used with the SSH2 protocol.

The first key is generated as follows:

ssh-keygen -t rsa
Ssh-keygen will respond as follows:
Generating public/private rsa1 key pair.
Enter file in which to save the key (/home/yourname/.ssh/id_rsa):
Just press return. Then ssh-keygen will ask for a passphrase (twice).

A passphrase is like a password except it can be any length and can contain whitespace, punctuation, numbers, almost anything.
"Aunt Nellie's toe nails smell like rotten eggs to me"
is a valid passphrase.

Enter passphrase (empty for no passphrase): 
Enter same passphrase again:


Don't create an empty passphrase! There is no security enforced. That is, anyone who can get to the files, can run the files.

Ssh-keygen will then display some information and quit.

Now issue the following ssh-keygen commands to create the other keys:

ssh-keygen -t dsa
ssh-keygen -t rsa
Note that you are entering 3 separate passphrases. They may all have the same value or each may be different from the others.

Copying Keys#

You should now have 3 pairs of keys in the directory ~/.ssh. The files with the .pub extension are the public key files. The others are the private key files.
You must copy the content of the public key files to every remote machine of interest.

You may need to create the directory ~/.ssh on the remote machines if it doesn't exist:

cd ~
mkdir .ssh
chmod 640 .ssh
Now you've got to get the content of the public key files to the remote computers. The easiest way is to open an editor on the local machine and then to connect to a remote machine (via ssh of course) and start an editor there. Then you can cut and paste between the editors (using whatever cut and paste mechanism your operating system provides).

The content of ~/.ssh/ on the local machine goes in the file ~/.ssh/authorized_keys on the remote machines.

The content of the ~/.ssh/ on the local machine goes in ~/.ssh/authorized_keys on the remote machines.

Likewise, the content of the ~/.ssh/ on the local machine is appended to ~/.ssh/authorized_keys on the remote machines.

The file authorized_keys may contain public key content from many clients. Simply put each public key entry on a separate line.

So, being lazy, we can:

# Repeat these steps on each remote system
scp ~/.ssh/

# Run these commands in the remote shell
if [ ! -d ./.ssh ]; then mkdir ./.ssh; fi
cat >> .ssh/authorized_keys

And then for automation we can: Create a hostnames.txt file containing the list of names of hosts we want to exchange keys with. Each host name on a separate line:

The Agent#

The Agent is the program, ssh-agent, that runs on the local machine and acts as your proxy when an ssh command requires a passphrase.

Normally you would type a password or passphrase when requested by ssh or scp. However, the agent can provide the passphrase for you. The trick is telling the SSH commands to get the passphrase from the agent rather than you. First you must ``prime the agent and then you must ``attach the agent to one or more processes.

Priming the Agent#

To 'prime' the agent issue the following commands (on the local machine):
ssh-agent >$ssh_info_file
chmod 600 $ssh_info_file
. $ssh_info_file
ssh-add ~/.ssh/identity
ssh-add ~/.ssh/id_dsa
ssh-add ~/.ssh/id_rsa
Each ssh-add command will prompt you for the appropriate passphrase.

Note the output of hostname is appended to the name of the ssh agent info file. This distinguishes the name of the file from other instances of the file that may be created in a multi-host, shared home directory environment.

It's convenient to capture this sequence in a shell script:

# Creates an ssh-agent, writes ssh agent info
# to the file '~/.ssh-agent-info-`hostname`' and then prompts
# user for keys.  Then any shell can use the agent
# by sourcing the contents of ~/.ssh-agent-info-`hostname`:
#  . ~/ssh-agent-info-`hostname`

ssh-agent >$ssh_info_file
chmod 600 $ssh_info_file
. $ssh_info_file
for i in identity id_dsa id_rsa
    ssh-add .ssh/\$i

Save this script as ssh_prime in your home directory. Now you can type:

source ssh_prime
You need only "prime" your agent once each time you reboot your machine. The agent will stay active across logins.

Now you should be able to connect, without entering a password, to all remote machines that have the public keys you generated earlier.

Note that the shell command source ssh_prime both primes the agent and attaches it to the current shell process (and its children). However, in some cases (example given below), you may need to explicitly attach the agent to a process after the agent has been primed.

Attaching the Agent#

Attaching the agent to a process is easy. For example, start a new terminal session and type:
. ~/.ssh-agent-info-`hostname`
This attaches the agent to the terminal process (as well as any future processes that are children of the terminal process).

Now you should be able to connect, without entering a password, to all remote machines that have the public keys you generated earlier.


We found many different ways to do this from the internet and from experienced administrators. It is important that the process be understood more than the method of performing the process. Performed improperly you could expose a lot of security risks.

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-5) was last changed on 12-Feb-2009 11:10 by jim