incoming ssh/sftp blocked by iptables

[Fulko.Hew at sita.aero]

> On Thu, 2004-04-15 at 00:02, Fulko.Hew at sita.aero wrote:
> > The trouble... for dumb users... is that if they enable SSH
> > they won't know that they _also_ need to re-config their firewall.
> > They'll just complain that stuff doesn't work.
>
> I am not sure that I fully understand your premise.

Basically, a friend asked my why SSH/SFTP didn't 'appear' to allow incoming
calls.
(Keep in mind that we have both been in the data comm business writting
protocols for a living for over 20 years...)

And we both had to spend time trying to figure out:

a) what the cryptic messages implied.  ie. "no route to host"
b) that it was being caused by iptables
c) how to workaround (disable iptable rules) or add a new rule.


> I enable httpd on my
> machine so that I can test various things. I would not want my actions
> to open the firewall behind my back. Or do you mean that the user should
> be asked if he wants the firewall opened?

I can't speak for httpd, but I expect that it would fall under the same
rules.  ie. you can enable it, but it still won't work (from outside your
box).
(Yup, I just tried it.)

My problem with the concept, and I understand and appreciate why its
there...
is that from a 'user perspective' they won't understand why it doesn't work
for them, and they have _no_ indication of where to go to fix it.
I'm an experienced guy, and _I_ didn't know.  How do you expect my "mother"
to know?

The 'system' needs to direct the user to prevent frustration.
An adage I use when developing software and writting manuals is:

"If the user had to ask a question, I didn't do my job right!"

The software either didn't do what was expected, and/or
didn't direct the user on 'other' things they needed to do,
and the documentation was missing or too cryptic to find out
how to do the 'unknown' extra step.

I guess thats my point.  How is someone to know where and how to
find the (now) 'extra', 'missing' step?