Connection caching?

[Jefferson Ogata]

Damien Miller wrote:
> Jefferson Ogata wrote:
>>Damien Miller wrote:
>>>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.
> 
> We are going in circles. You don't seem to want to understand that if
> you don't trust the client, then no amount of server configuration is
> going to prevent them from being taken over.

And you don't seem to want to understand that at least one-time password 
authentication renders the authentication process itself secure. But when you 
provide a mechanism that extends a single authentication into unlimited sessions 
you lose the opportunity to control the scope of a compromise.

I can set up a secure ssh gateway that requires pubkey or OTP auth to get in, 
and OTP to get out to the secure network. I can make the client secure on the 
gateway, and prevent users from adding code on the gateway. I can disable port, 
X, and agent forwarding on the gateway. That's a pretty strong setup even if the 
remote client is compromised; the worst case is that a very talented intruder 
/might/ hijack a single session at the remote end, and that would be detectable. 
Moreover, most intruders are too stupid or lazy to even try to take over an 
existing session.

Just because a user can still theoretically tunnel his own protocol through all 
that doesn't mean it isn't obvious that there should be a server control for it. 
A user can tunnel X without help from sshd -- that doesn't mean we don't have a 
X11Forwarding directive.

Are you really going to say you don't see the danger of a single authentication 
session providing a tunnel for unlimited shells, with /no way/ to disable that 
behavior? You don't see how that makes it harder to mitigate the scope of a 
remote compromise?

>>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?
> 
> No, obviously I don't. Neither, obviously, did any of the authors of
> the SSH v.2 protocol where this capability is pretty much mandated
> by the spec.

If the spec truly mandates this silliness, that doesn't mean it isn't clearly 
wise to provide a mechanism to disable it.

> On the other hand, maybe we just understand the implications of
> allowing an uncontrolled client to authenticate better than you. Please
> think this through before throwing more insults around.

I have thought it through. And I've got plenty of real world experience in 
dealing with web-of-trust intrusions involving openssh. Making it easier for 
lazy users to bypass authentication doesn't help -- particularly if you don't 
provide a directive to control it on the server end. In the real world, 
sysadmins have to provide shells to remote bozo users. They need every control 
imaginable to keep compromises contained to the utmost degree possible. There is 
no perfect defense, but there is also no such thing as a perfect attacker.

>>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.
> 
> We have lives outside of OpenSSH and sometimes we are too busy to
> jump when you expect us to. Especially for patches against a 2 year
> old version.

The patch was against the version distributed by Red Hat. For many people, 
that's a convenience. I offered to update it if it would make any difference. 
Sounds like it might have, but I didn't hear anything either way.

> Please post your patch to bugzilla, a service that is provided so
> things like that don't get lost.

Well, that's actual feedback, finally. Thanks for the suggestion.

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