On Tue, Sep 13, 2005 at 02:31:54PM -0400, Sam Hartman wrote:
"David" == David B Harrington <ietfdbh(_at_)comcast(_dot_)net> writes:
David> Hi, Personally, I'd rather see the issue of working through
David> NATs and firewalls solved at the SSH level, and then SNMP
David> and other SSH-using applications, such as Netconf and CLI,
David> could use the solution in a consistent manner.
I think that the ssh connection application already has a fairly
reasonable story for NATs and firewalls, so I don't see much of a need
for ssh itself to advance in this area.
For the most part people who block port 22 really do intend to block
ssh and so having standard facilities to get around that would not be
appropriate. The port forwarding support in ssh seems to be an
adequate solution for NATs.
Sam,
this is not about blocking port 22 as far as I understand things. I
think the issue here is that TCP connection establishment determines
ssh client/server roles. If there would be a way to initiate the
connection but subsequently taking over the server role, protocols
like netconf and presumably isms would find it much easier to provide
CH functionality.
/js
--
Juergen Schoenwaelder International University Bremen
<http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen, Germany
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf