[EMAIL PROTECTED] on 05/30/2000 01:53:30 PM

To:   [EMAIL PROTECTED]
cc:
Subject:  Re: request for key use restriction (Was: key configuration?)





>Ah. The "r..." commands pass the username from the client to the server
>as part of the initial connection negotiation. The server checks the source
>port is < 1024, and that therefore the client program is running as "root",
>and that therefore the client software hasn't been got at to make it provide
>incorrect data *unless the client computer has been root-compromised*. The
>"r..." servers do *not* use the "ident" service.
>
>The "RSAHostAuthentication" mode of SSH does the same thing, with the addition
>of using RSA suthentication *of the identity of the client and server machines*
>to guard against IP spoofing.
>
>The "RSAUserAuthentication" mode of SSH relies on the users private key.

How does the server use the "from" description in authorization?  Why can't
something similar occur for the username?  For example, once the user has been
authenticated with the key, send over the client's username and double check it
against what's in authorization.  I don't see how such an enhancement would make
SSH less secure.  In fact, I'd think it'd be more secure since it'd be harder to
use stolen keys.

>I don't know of a way of activating both tests at once. In any case, an
>unreliable client machine or unreliable users on a client machine is
>*always* a problem.

I agree in general, but I don't think this is too much of a problem here (or at
least I don't feel it's worth guarding against here -- after all, we're talking
about machines that're already on the internal network).

> If they give away SSH "identity" files they'll give
>away passwords for usernames; although maybe not *quite* so easily
>because of traceability. But a username check only works if the usernames
>on the client machine can be relied on.

Again, we're trying to guard against copied keys, not hackers.  I would even say
that if they know how to spoof usernames, they probably already have access to
the user keys without the users' permissions.

> This implies that the machine
>must be running a real multi-user OS, and *that* rather implies that it's
>*likely* the end-users will be on remote desktop machines.

Does NT pass as a "real" multi-user OS?  Why or why not?

One of the problems I'm trying to guard against is that it's fairly easy for
others to steal private keys (and also easy to give away private keys).  If the
keys can only be used by specific users on specific hosts, it'll be that much
more difficult to use stolen keys (one would have to spoof both the hostname and
the username).

> So, install
>"SSH" *on the desktops* with the "identity" file stored there, use SSH
>to login to the shared machine from those desktops, and use the ssh-agent
>forwarding to give access to the "identity" files stored on the desktops
>from the eventual target machine via the intermediate one. That won't
>stop them "swapping" keys, but will make it much clearer what's happened,
>and the users will have less excuse for the misbehaviour.

I don't understand.  Can you elaborate?

Thanks,
Noel



This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan & Co. Incorporated, its
subsidiaries and affiliates.

Reply via email to