Connection caching?

[Ben Lindstrom]

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'.

'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.

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).

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.

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. =)

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

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?

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


- Ben