Connection caching?

[Jefferson Ogata]

Ben Lindstrom wrote:
> On Wed, 5 May 2004, Jefferson Ogata wrote:
>>Ben Lindstrom wrote:
>>>On Wed, 5 May 2004, Jefferson Ogata wrote:
>>>
>>>>No doubt the lazy user /would/ enable such a thing. The control needs to be on
>>>>the server side.
>>>
>>>Praytell... If the /home is RO.. they don't have a ssh_config or it is
>>>predefined for them.. How is:
>>>
>>>ssh -G somesite.com
>>>
>>>or worse:
>>>
>>>ssh '-o AllowMultipleChannels yes' somesite.com
>>>
>>>is easier than just typing:
>>>
>>>ssh somesite.com
>>
>>It's not easier the first time, but it's easier for all the subsequent times
>>where authentication gets bypassed. I'm confident you understand this, so why
>>are you asking?
> 
> Not easier the second time either..
> 
> First time:
> 
> ssh '-oPipeLoc /tmp/foo/host-%h'-G host
> 
> then
> 
> ssh -P '-oPipeLoc /tmp/foo/host-%h'
> 
> Since as you claim /home is RO and is useless to them, then /tmp is their
> only valid refusage to use 'connection caching'.

AFAIK, the specific default location for the connection cache socket hasn't been 
determined. ssh-agent puts its socket under /tmp.

You keep trying to pick away at details of this gateway set up, but you seem 
unable to comprehend that it's merely an example. There are many other variants 
-- home directories writable but profiles immutable, systrace or similar 
deployed to allow normal ssh client behavior but block pty hijacking, etc. -- 
there are many other ways to configure a secure gateway. Try to understand the 
bigger picture -- /try/ to understand that sshd should not undermine the 
sysadmin's ability to enforce as many controls as possible.

> 'MaxChannelsPerConnection' can only hold up in an environment like
> the one you describe where all gates in and out are bared and force
> reauthication in order to unlock.  Which is the minority not the majority
> of all sshd setups.

A minority for you perhaps, but not for me. In any case, why should "secure 
shell" undermine a more secure environment in favor of a majority of less secure 
ones?

> I already have a -L/-R concept floating around in my head that could
> bypass MaxChannelsPerConnection without such a protective proxy (if I
> bothered to setup and review and study the proxy setup I'm sure I could
> come up with theories on bypassing it also).

Yes, some user might do that. I've already allowed that, over and over. But not 
every user will.

Have you ever dealt with a web-of-trust compromise? I suspect not...

> Which is the point here.  You honestly think it will stop a lazy person?
> I've met a few very pigheaded people that will do everything they can to
> setup long standing badly formed trusts so they can avoid passwords/OTP/etc.

With cached connections, no one has to work to bypass authentication -- it's 
practically the default, at least as pitched earlier in this thread. What about 
this don't you understand?

> Heck, I'm sure we all read the article about how most users would give up
> their passwords for Chocolate, and some don't even need the chocolate. =)

If you offer my users a bar of chocolate in exchange for the floppy I gave them 
with their RSA private key, /and/ their S/KEY password list, I think they'll balk.

>>>Still my oritinal point stands from a few messages ago.. NOTHING stops
>>>this from happening now from a client other than ours.  Yet you don't
>>>seem to care about that fact... Only after we commented that "someday
>>>this would be a nice feature" did you start...
>>
>>Obviously, I /do/ care about that fact -- that's why I've been explaining the
>>issue with scenario after scenario so you can see why the control needs to be on
>>the server side, and why it should have been there all along.
> 
> The control is still yet an illusion.  And is that illusion worth the cost
> of the code needed to give the admin warm fuzzies when it can be so
> easily bypassed in the majority case?

The X11Forwarding control is an illusion. It's there, however, because it is in 
fact possible to arrange an environment where it actually works.

> Also, if our sshd supports multiple channels per session now, and other
> ssh clients support it.  Why only complain when someone suggests we
> support it?  Is not the security of your chokepoint also in question here?
> Are you so sure that you have no buffer overflows (or 100% sure that your
> mitigation works perfectly.. E.G. PAX recent DoS)?  Either in setuid
> binaries which would easily grant access.  Or non-setuid binaries which
> could be used for a shell code attack to extract useful information?

As I think has been made totally plain, I complain now because I wasn't aware 
that openssh sshd supported it until it was discussed in this thread.

>>>If you want the feature.. Pony up the code so we have something physical
>>>to discuss and test against other SSH clients for breakage.  Until then I
>>>think we are going in circles.
>>
>>If/when I have time. Or I might evaluate other versions of the server. Or maybe
>>someone else with some spare time will understand why this is important and
>>write a patch.
> 
> <shrug> Nothing stops you.  And frankly if it is important to you after
> the SSH client supports multiple channel communications it should be
> important to you now, because you still are at risk in your mind.

Yes, it is important to me. That doesn't mean I have time to write a patch at 
this time, however. It does mean I might recommend to the admins I support that 
they stop allowing remote access via openssh until this is resolved.

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