Verification of public and private key generation

[Andrew Kaplan]

Hi there --

We are running HP-UX 11.11 on an 9000/800 platform system that also has the  HP Secure Shell server A.04.70.009 package software. I need to verify a statement that I made to my supervisor concerning the creation of public and private keys and I was hoping someone could provide insight on this.

The situation is the following: A specific non-root user account on the server is being used via an SSH connection to access an X application on the server on a remote system. The remote system is a terminal server that, in turn, will be used by other workstations to run the application. Part of the setup process is to generate public and private dsa keys for the user account.

The question that I had was the following: As long as I am logged into the server as the user account in question, when the keys are generated, they will be generated specifically for that user account, and not for all users or for the server itself. Correct? 

[Steven Schweda]

> The question that I had [...]

   It may be clear to you which "server" is "the server", but I got
lost.  In any case, key files are not generated "for that user account".
They are not user-specific that way.  Key files are files.  They exist
somewhere.  Someone owns them.  They have some permissions (and/or other
access control attributes).  SSH doesn't care who made them.  It doesn't
care much about where they are (although there are default names and
locations), but it is a little fussy about ownership and permissions,
especially regarding private keys.  (Public key files may be readable by
anyone.  They are called "public", after all.  Private key files need
tighter access restrictions, or else SSH won't trust them.)

   If you copy these files around, and let many users control their own
copies, then any number of people can use them.  If you restrict access
to these files, then only those users who can get to the files can use
them.

   As usual, though, my advice is not to trust free advice.  It should
be relatively easy to run the experiment.  For example, drop copies of a
set of key files into the "~/ssh" directory for a couple of users.
Adjust the ownership and permissions as needed.  See what works.  I
could be bewildered, and you'll find that one set of key files works for
only one user.  But I doubt it.

   A clearer explanation of what you want to do, and what you want not
to happen might help.

[Doug O'Leary]

Hey;

Steven is correct; however, it's not quite as bleak as he's laying it out.  First, as a short answer, assuming you are using a "default" environment, then, yes, the keys that users generate are user specific.  There are some caveats to which Steven alluded.

First, there are system level keys that the source and target hosts use to verify the others identity and used to generate a symmetric key for the general encryption.

If your users generate their own keys, they will, by default, be placed in ${HOME}/.ssh/id_dsa and ${HOME}/.ssh/id_dsa.pub.  There are also rsa variants.  As long as you keep the envionment like this, then the keys are user specific.

There's nothing preventing a user from copying his private key over to another system or giving a copy of the private key to another user on the system.  Why anyone would do this is beyond me, but I've long since stopped trying to follow user logic.  

You can identify if keys are the same with relative ease.  Simply search through the home directories for the keys, then run "ssh-keygen -l -f ${key}".  That will show a hash or a key fingerprint.  Loop through the keys, | sort -u, and you'll see if you have any duplicates.

Hope that helps.

Doug O'Leary