I don't understand this discussion. checking usernames doesn't make anything more secure. what needed is the integration of managed Public Key Infrastructure software into SSH. SSH maintains it's own key formats and it supports PGP keys. In a larger environment it will be necessary to support X.509v3 certificates in combination with certificate revocation lists, certificate servers which can be accessed by LDAP and a trustcenter which controls issuing of certificates and companywide policies. The patch request should be to support trustcenter products from Entrust, Baltimore and so on. Stefan > -----Original Message----- > From: Noel L Yap [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, May 30, 2000 11:23 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: request for patch: key use restriction by user > and hostname > (Was: key configuration?) > > > > > > > [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. >
