Protocol Version Exchange: the comments field and an idea how to use it

[J's Mail]

What you describe can be configured today, with no development effort at
all.

external proxy/gateway
sshd_config:
Match Group proxy_user
  ForceCommand  /bin/false

client machine
ssh_config:
Host private_internal_machine
  hostname 192.168.1.22
  ProxyCommand ssh proxy -W %h:%p

---
This particular configuration would require the proxy/gateway machine to
have credentials configured for the desired accounts.  This may or may not
be a stumbling block.  I would argue that you want some form of access
control and a nice PAM configuration would allow you to centrally manage
both the proxy and the internal machine accounts.

A note on the sshd configuration of the proxy machine:  This isn't strictly
necessary.  What it is intended to accomplish is deny local access on the
proxy machine.  This could be enforced in other ways.  I'd like to hear
comments on this.  Currently, the ssh client can specify -N, instructing
the daemon to not execute a remote command.  For the use case here, I'd
like to see this enforced from the server side with an sshd option
NoCommand.

-- Jess





On Wed, Nov 13, 2013 at 6:17 AM, Hannes Hörl
<hannes.hoerl at snowreporter.com>wrote:

> Good day!
>
> As stated in [1] ("Protocol Version Exchange") there is a "comments"
> field, which gets transferred in plain text before setting up the
> encrypted connection. I couldn't find anything specific in which cases
> one could or should use this field - so i figured I can use it how ever
> I want.
>
>
> So here is my basic idea:
>
> With a command line switch (or configfile entry) the openssh client uses
> the said comments field to send the (maybe hashed) hostname the user
> wants to connect to (or any other info for that matter).
>
> Now on the serverside one could deploy a small proxy which listens on
> the default ssh port. When receiving the Protocol Version and this
> comment this proxy could decide (based on the unencrypted stuff) where
> to pipe this connection to. This could be used to route ssh connection
> from a frontend machine to a backend machine without intercepting the
> encrypted connection and without having multiple ports open which
> forward to the ssh port on the internal machine.
>
>
> My question:
>
> What did I miss - there must be a problem somewhere
>   - This shouldn't interfere with any other standards compliant ssh server
>   - I can't really think of any security problems (given there are no
>     errors in the implementation itself)
>   - Looking through the openssh code it shouldn't be to hard to
>     implement for the openssh-client
>   - Said proxy should be relatively easy to implement too
>   - I think this could be extremely helpful for various situations
>
> Any input on this idea would be very much appreciated!
>
> Thank you & bye,
> Hannes
>
>
> [1] https://tools.ietf.org/html/rfc4253#section-4.2
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>



On Wed, Nov 13, 2013 at 6:17 AM, Hannes Hörl
<hannes.hoerl at snowreporter.com>wrote:

> Good day!
>
> As stated in [1] ("Protocol Version Exchange") there is a "comments"
> field, which gets transferred in plain text before setting up the
> encrypted connection. I couldn't find anything specific in which cases
> one could or should use this field - so i figured I can use it how ever
> I want.
>
>
> So here is my basic idea:
>
> With a command line switch (or configfile entry) the openssh client uses
> the said comments field to send the (maybe hashed) hostname the user
> wants to connect to (or any other info for that matter).
>
> Now on the serverside one could deploy a small proxy which listens on
> the default ssh port. When receiving the Protocol Version and this
> comment this proxy could decide (based on the unencrypted stuff) where
> to pipe this connection to. This could be used to route ssh connection
> from a frontend machine to a backend machine without intercepting the
> encrypted connection and without having multiple ports open which
> forward to the ssh port on the internal machine.
>
>
> My question:
>
> What did I miss - there must be a problem somewhere
>   - This shouldn't interfere with any other standards compliant ssh server
>   - I can't really think of any security problems (given there are no
>     errors in the implementation itself)
>   - Looking through the openssh code it shouldn't be to hard to
>     implement for the openssh-client
>   - Said proxy should be relatively easy to implement too
>   - I think this could be extremely helpful for various situations
>
> Any input on this idea would be very much appreciated!
>
> Thank you & bye,
> Hannes
>
>
> [1] https://tools.ietf.org/html/rfc4253#section-4.2
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>