On Wed, Jun 26, 2013 at 9:38 AM, Kent Watsen
<kwatsen%juniper.net@localhost> wrote:
On 6/26/13 9:09 AM, "t.petch" <ietfc%btconnect.com@localhost> wrote:
>
>Yes! That is exactly what I said. But what I also said is that Kent
>says
>" It works fairly well for automating the discovery of devices with
>static IPs
>on a reachable network, but not at all when the devices are behind a
>firewall that won't allow inbound SSH connections."
>
>Works not at all .. when the devices are behind a firewall.
>
>So if devices behind a firewall is a requirement, then the design fails
>to meet it.
>
>If that is not a requirement, why has Kent raised it (and it has been
>raised before)?
>
>This should confuse everyone (not just me:-)
Hi Tom,
By saying a firewall wouldn't allow inbound SSH connections, let's
simplify and assume the firewall doesn't allow any inbound TCP
connections, but outbound TCP-connections are fine.
The proposed solution is to repurpose the TCP connection initiated from
behind the firewall. Once the network management application accepts the
TCP connection, it can pass the accepted TCP socket into its SSH client of
choice (e.g. a SSH library like J2SSH or even using OpenSSH's
"ControlPath" parameter). On the "device" side, the accepted TCP
connection can be passed into an SSH server - for instance using `sshd -i`
exactly like `inetd` would do when listening on port 22.
Does it make sense now? [Martin is right that this section of the draft
could be clearer]
There are valid use-cases (e.g, SOHO) for wanting a manageable device
to connect to its manager from behind a firewall. IMO it's up to the Security Area
to figure out how to do that, not NETCONF, but as long as the proper reviewers
are found, that is not too important.
Does the client have to be pre-configured with all the keys of the servers
it will accept these connections from in advance? How does the client decide
to start an SSH session on the open connection or just drop it?
Thanks,
Kent
Andy