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

[Kent Watsen <kwatsen%juniper.net@localhost>]

> Firewalls should adapt to good protocol design; protocol design should
> not be weakened to work with firewalls. (And I say this as someone who
> likes firewalls.)

Agreed - let's focus on a good protocol design ;)



>> How many ssh-based protocols are there currently?  I only know
>> of two (SSH/SCP/SFTP:22 and NETCONF:830) - are there any others?  
>
> You say that as if we never expect to have any more, which seems like 
> poor planning. For example, many people run VNC and other such protocols
> on other ports. The "ssh -L 15901:localhost:5901 example.com" usage is
> quite common. Making it harder for protocols other than NETCONF to use
> SSH doesn't seem like a good plan at this point.

I didn't mean to imply that there wouldn't be more, only that there are
so few now and that new SSH-based protocols can define a reverse-port for
themselves, if it makes sense to them to do so.

I use that port forwarding line with my virtual machines.  It's a good
example because VNC is used to "manage" devices similar to NetConf, so
it's plausible that a device might be configured to init a reverse ssh
connection to support VNC.  In this case, the `ssh` connection goes to
port 22, so reversing it means that the device would connect to the 
application's rssh port and, once the SSH Connection Protocol (RFC 4254)
is running, the application can send a SSH_MSG_CHANNEL_OPEN/direct-tcpip
request to open a tunnel to the VNC server.




>> What does this means at a protocol level?  Does the application present a
>> SSH host-key during DH key exchange and the device logs into the application
>> via userauth?  - if so, then please realize that this is exactly what we're
>> trying to prevent.  
>
> I do realize that; I am proposing that what you are trying to prevent is 
> in  fact fine, and a lot more rational than a "I'm a kind-of-server for 
> just a moment" design.

Thanks, Paul.  I appreciate your endorsement.  At least, I think it is an
endorsement... (I'm not entirely sure per your last comment below)




>> We want the device to always be the peer that presents
>> its SSH host key, whether due to the application connecting to its port 22
>> or because the device connected to the app's Reverse SSH port.   Likewise,
>> we always want the app to be the peer that userauth's to the device, 
>> regardless how the transport was setup.
>
> Understood. The draft does a reasonable job of matching that design.
>
> 
>> This would only be necessary if there are no new port assignments as, 
>> otherwise, each peer *knows* which role to assume.  For instance, each
>> peer knows its role if started like this:
>> 
>>  app:     ssh --listen <rssh-port> --handler /usr/local/bin/myapp
>>  device:  sshd --connect <app>:<rssh-port> --id 234230 --hmackey secret
>>  
>> Otherwise, if there are no new port assignments (i.e. <rssh-port>==22),
>> then we'd have to have in-band negotiation, perhaps by the device 
>> sending a special identification string (RFC 4253, section 4.2) like
>> this?
>> 
>>  SSH-2.0-OpenSSH_5.6 <SP> Reverse SSH <CR> <LF>
>
>This assumes that all SSH use is only on the currently-assigned ports. That ignores the "-L" use >case I gave above, as well as future protocols that want to run over SSH.

FWIW, I personally don't like repurposing the currently-assigned ports 
because it would be confusing to suddenly not be sure that port 22 was
for a SSH Server and port 830 was for a NetConf server.  I only offered
how we might support in-band negotiation with the identification string
because it seemed folks wanted to explore that option.  

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.  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?)

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.




>> 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?



Thanks again,
Kent