Re: Sharing the SSH server keys & other questions
From: Darren Dunham (ddunham_at_redwood.taos.com)
Date: 06/26/04
- Next message: Bill Unruh: "Re: Sharing the SSH server keys & other questions"
- Previous message: Carlos N: "OpenSSH for Windows - sshd logs"
- In reply to: Carlos N: "Sharing the SSH server keys & other questions"
- Next in thread: Bill Unruh: "Re: Sharing the SSH server keys & other questions"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Fri, 25 Jun 2004 23:58:01 GMT
Carlos N <cgnjunkregDELETE@hotmail.com> wrote:
> Basic SSH question:
> If I want to use RSA authentication by clients the process is simple. I
> generate a key pair, leave the private key (encrypted or not) on the
> client, give the public key to the server, make sure the server knows
> about it and presto.
Note that other machines may or may not have access to the public key
generated this way, but we really don't care. It's just a public key,
so someone could authorize this machine with it, but they couldn't use
it to change the access in place or to decrypt streams.
> This makes sense. The server administrator has to actively accept the
> clients key, insuring that not just anyone can login.
> However, it seems that the reverse is not true. The server also has a
> private/public key pair (whether using key or password
> authentication).
Yes.
> It seems, however, that the server automatically will feed its public
> key to the client. The client checks to make sure the key is OK - sure
> that protects the client. But it seems like ANY client can connect and
> automatically gets the key. Is there a way to limit the exchange so
> that the admin has to hand out the server's key through a different
> channel? Am I missing the point?
Why do you care if the server's public key is handed out?
> In case you are wondering... I'm trying to set up a very simple SSH
> server on my home machine, so my wife can access it remotely. It seems
> like handing out the server key manually would be a way to restrict
> passerbys from trying to log in. Of course, the password and/or client
> key does the same thing. I'm just wondering....
That's exactly what the password and client keys are for.
How is not handing out a server's public key any more secure than not
authorizing a user's private key?
> On a very related note. Since she will be traveling, sometimes using
> her laptop, sometimes using internet cafes or hotel computers, it seems
> like the best option is to use password rather than key authentication.
> Is this correct? This way she doesn't have to install a new key in
> each place. It also seems to preclude my doing any host-level access
> privileges in SSD.
You would certainly want to avoid installing a private key onto machines
you don't control. Leaving a single private key on her own laptop seems
a sensible solution.
For remote machines, I'd generally prefer password authentication, but
even there a keylogger or other items could gain the secrets. If you
really want to avoid those kind of threats, you'd need something like
S/Key or SecureID so that the items given to or typed on the local
machine are not secrets.
-- Darren Dunham ddunham@taos.com Senior Technical Consultant TAOS http://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area < This line left intentionally blank to confuse you. >
- Next message: Bill Unruh: "Re: Sharing the SSH server keys & other questions"
- Previous message: Carlos N: "OpenSSH for Windows - sshd logs"
- In reply to: Carlos N: "Sharing the SSH server keys & other questions"
- Next in thread: Bill Unruh: "Re: Sharing the SSH server keys & other questions"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
