IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt




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]

Thanks,
Kent











Home | Main Index | Thread Index | Old Index