"The dimly light light bulb above his head burned bright it actually burst..."
I believe part of my problem was that I am (was) confusing the "sever tools" with some of the "client tools" used with SSH.
It seems that all I need to do is create (using ssh-keygen or a similar tool) the pub/pri key set for each user on the server/servers we will be accessing with SSH. This will create the .ssh directory in their home directory and place the necessary identity files in the dir.
At that point I need to (securely) get the users a copy of their pub to be used with their SSH client software.
From then on it should be (what I hope to be simple) a manner of controlling the pri key for each user on the server???????
One other question concerning passpharse...
The purpose of using a passpharse is to provide some extra security for the identity file used with the SSH client?
I do not have to use a passpharse with generating the key set but it does not seem like a bad idea???
Again, THANKS for your feedback
Vinson
-----Original Message-----
From: Brandon Fitch [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 02, 2001 5:42 PM
To: Vinson Armstead - PA
Cc: [EMAIL PROTECTED]
Subject: Re: Suggestions on setting a SSH server to authenticate
multiple user s
it depends on your environment, and how much you want to balance
security vs. ease of management. 'ssh-agent' is used by the end user
to manage their own keys. This is a great tool if you use different
keys to get onto different systems. You add all the keys to the agent,
and you don't need to worry about them again until next time you login.
But as an SA, it won't help you in managing keys.
There are different ways of managing keys. Here are a few examples:
1 - Give each user their key on a CD or Floppy. This ensures each user
has received their own public key. Hard to do in large environments
though. The goal here is to get the key to the users securely, and to
be sure it does in fact get to the person intended. You could also
give the users key to them through an encrypted email, but if you
aren't already setup to do this, it's more of a hassle for this
one end result.
2 - Allow password authentication and allow users to setup their own
pub/private keys. This is a bit less secure, and if you really want
users to use pub/priv keys, then this is a bad idea. Chances are
most will just keep using their passwords.
3 - Set up LDAP to store the public keys on. Then all systems you
want them to authenticate too can get the public keys off of an
ldap database. It's ok to have your pub key available to others.
The end user needs to be concerned with keeping the private key
a secret.
I'm sure there are a lot of more creative ideas then this. You need
to decide what are your requirements, how secure you are trying to
make this, and find the best path that suits your needs. You also
need to decide if these keys are used to access one system, or
many. And remember, if they are used to access many, one stolen
key (off a stolen laptop for example) will allow a hacker to log
into ALL the systems that contain that public key. I'm not saying
not to do this, just be aware of this, and have a practice in place
for removing all the public keys for a certain user from every system
if this ever happends. This shouldn't be hard to also integrate this
with the practices you have to remove a user when they quit.
Hope this helps answer your question, or at least points you in the
right direction. Sorry for the length. I didn't expect to go on
and on and on... ;)
--brandon
On Tue, Oct 02, 2001 at 04:50:51PM -0400, Vinson Armstead - PA wrote:
> Ok, I agree with the "each has their own" rule...
>
> What is the best way to manage that solution is my real question.
>
> Do I use ssh-agent?
>
> I read in the SSH text that you can "somehow" load each users key info via
> their login script using ssh-agent but have not had much success.
>
> Any suggestions??
>
> Thanks again for the reply
