Connection caching?

[Jefferson Ogata]

Damien Miller wrote:
> Jefferson Ogata wrote:
>>Um, I feel like you're missing the point. I can prevent users from using 
>>ssh-agent by not providing the binary and by not giving them write access to any 
>>exec filesystem. I can also require authentication mechanisms on the server side 
>>that ssh-agent cannot answer, e.g. one-time passwords. The mechanism under 
>>discussion is not amenable to any of these controls. Once someone authenticates 
>>once, if that user's remote session is compromised, the intruder can piggyback 
>>over any established ssh connection and there is absolutely no way I can force 
>>the intruder to authenticate. Do you understand? 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.

>>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?

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.

-- 
Jefferson Ogata <Jefferson.Ogata at noaa.gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>