Re: [saag] draft-kwatsen-reverse-ssh submission for review

[Joe Touch <touch%isi.edu@localhost>]

On May 23, 2011, at 4:17 PM, Kent Watsen <kwatsen%juniper.net@localhost> wrote:
> 
> I like having a single well-known port (like tcpmux/port 1) that can be
> used for any SSH-based protocol, leaving it to the client to select which
> ones to start via opening channels/subsystems.  

Why isn't that the current ssh port?

> For instance, an app can
> have simultaneous channels open for Syslog, SNMP, NetConf, VNC, HTTPS,
> and TTY.  Which reminds me that I've always wanted an ability for a SSH
> Client to get a listing of all the subsystems available on the server, 
> similar to tcpmux's "HELP" command (another draft?)

That is what the dns srv records might do, so you could ootentkially use 53 for that. But wouldn't that be a security concern?

> Another option, that I'm a bit shy to promote, is to have *no* assigned 
> ports.  This is technically feasible since the devices MUST be configured
> to connect to the applications (i.e. address, port, id, credentials, etc.).
> The devices never connect out of the blue, thus no well-known port is 
> required.  But this strategy would entail applications using unassigned
> ports, the very thing that Joe Touch flagged the day I submitted the draft.

Using only ports from the dynamic range is fine, but won't appease firewall designers. 

Using the entire port range, or and single port that is from the assignable range that hasn't been assigned to you is a problem (and I was concerned with the latter in your submission).

> 
>>> If having in-band negotiation, then we should also extend the SSH 
>>> Protocol to support device identification and automatic authentication
>>> of host keys other than PGP and x.509 certificates, this is the 
>>> essence of the REVERSE-SSH-CONN-INFO message in the draft.
>> 
>> 
>> That is one design; another is "when I am acting like a server, I am 
>> actually a server". That seems a lot cleaner.
> 
> This is the comment I mentioned above is being unsure if it means you
> like the current draft or not.  Is the "I am actually a server" statement
> satisfied by having an application listening on a Reverse SSH port, where
> the entire "protocol" is merely to bootstrap the SSH protocol?

I'm a server if I listen on the ssh port. On that port you should indicate or negotiate specifics of each side's behavior in-band IMO. 

Joe