openssh unix dev - Nov 2013 - Protocol Version Exchange: the comments field and an idea how to use it

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

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@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@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@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@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

Hi.

Just to be clear:
This all is just my imaginary use case. Anyhow, I think you could call 
the thing I''m thinking about "poor man''s SNI[0] for
SSH" ...

So my question(s) rephrased:
Why isn''t there anything like SNI for SSH? For security reasons? Is 
there no demand? Is there a better solution which I don''t know of?

On 11/13/2013 01:25 PM, J''s Mail wrote:
> What you describe can be configured today, with no development effort at
> all.
>   [...]
> client machine
> ssh_config:
> Host private_internal_machine
>    hostname 192.168.1.22
>    ProxyCommand ssh proxy -W %h:%p
If I understand this right this would make a ssh connection to the 
proxy, terminate it there - and make a second connection from the client 
machine to the backend machine, tunneled through the first ssh 
connection, right?
So anything needed (account, certs, ...) to authenticate a user on the 
backend machine needs to be setup and available on the proxy too.
> 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.
For my imaginary use case, the backend machines would be (virtual) hosts 
for customers, friends, ... where I have no idea about e.g. user 
accounts (or for that matter: I''d have no idea about anything going on 
on those hosts).
The only thing I know is, if there is a host with a certain hostname in 
my backend network or not. If so I''d like to pipe through the
connection
to the desired host. I don''t want to have any ssh connection to the 
proxy machine itself.

Therefor my idea:
   the magical ''-H''[1] switch (or some setting in the
ssh_config).

$ ssh -H user@www.mybackendhost.com

www.mybackendhost.com resolves to the IP of the proxy (there is already 
HAProxy running for proxying HTTP ...). The ''-H'' option
appends the
hostname (www.mybackendhost.com again) to the "Protocol Exchange
String"[2].

My proxy daemon then just has to listen to the first line (or first 255 
chars or whatever) and, based on this, can determine where the 
connection has to go. It doesn''t have to have any idea about ssh, 
encryption, ... itself. After finding the desired host, my proxy daemon 
just has to sit between the client and the backend host and forward data 
coming from either side to the other - without knowing, what this data 
is actually about.


Thank you for your input anyways!

Bye, Hannes


[0] https://en.wikipedia.org/wiki/Server_Name_Indication

[1] I just picked ''-H'' because it seams to be unused by now

[2] for example:
SSH-2.0-OpenSSH_6.4p1 www.mybackendhost.com

Hannes Hörl wrote:
>> Host private_internal_machine
>>    hostname 192.168.1.22
>>    ProxyCommand ssh proxy -W %h:%p
>
> If I understand this right this would make a ssh connection to the proxy, 
> terminate it there - and make a second connection from the client machine 
> to the backend machine, tunneled through the first ssh connection, right?
Yes.

> So anything needed (account, certs, ...) to authenticate a user on the 
> backend machine needs to be setup and available on the proxy too.
No.

The second logical connection is (as you write) indeed between the
client and the backend machine. Both the proxy and the backend
machine individually and independently authenticate their respective
connection, and in both cases it is the client machine on the other end.

> For my imaginary use case, the backend machines would be (virtual) hosts 
> for customers, friends, ... where I have no idea about e.g. user accounts 
> (or for that matter: I'd have no idea about anything going on on those 
> hosts).
> The only thing I know is, if there is a host with a certain hostname in my 
> backend network or not. If so I'd like to pipe through the connection
to
> the desired host. I don't want to have any ssh connection to the proxy 
> machine itself.
Why have a proxy if it allows to connect to any backend machine
without authenticating the request anyway?


//Peter
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 11/13/2013 08:25 AM, Hannes Hörl wrote:
> This all is just my imaginary use case. Anyhow, I think you could call
> the thing I''m thinking about "poor man''s SNI[0] for
SSH" ...
I''m not sure why it would be "poor man''s" -- your
proposal sounds very
similar to SNI from TLS.

There is currently a lot of discussion on tls@ietf.org about problems
with SNI -- in particular, that it leaks the name of the desired host to
a passive network attacker.  In general, it''s wise to be wary of
cleartext connection hints that are used in the negotiation of a secure
channel.

One of the ideas from the discussion about TLS is to move SNI within a
layer of crypto based on an anonymous DHE handshake, which puts it out
of reach of a passive attacker (of course, an active attacker who is
willing to cause a connection failure can still extract this information).

Note that SNI (in either TLS or in your SSH proposal) is not
"negotiated" in a strict sense. Is it offered by the client to the
server in the clear, in the hopes that it will be supported by the
server (but willing to be ignored if it is not supported).
> So my question(s) rephrased:
> Why isn''t there anything like SNI for SSH? For security reasons?
Is
> there no demand? Is there a better solution which I don''t know of?
Is it worth having clients advertise the server''s name in the clear on
the network if there is no proxy in use?  Your proposal neatly avoids
this question by making it disabled by default.

You should also realize that some distributors patch their clients to
add a comment string there anyway (e.g. Debian openssh puts "Debian"
in
the comment there).  So your proxy could get quite confused if it tries
to hand the connection off to the "Debian" backend.  If this is a
space
for hiding other sorts of cleartext connection "hints", then you
probably want to distinguish your "SNI" hint from other hints.  you
could perhaps do this by declaring it with a specialized prefix, like
"Host:", to distinguish it from othe uses of the comment field.  That
way a comment like "limburger Host:server.example.net" would be
cleanly
parseable.

If you decide this is really something that you want, I''d recommend
modeling your change on the patches that added the VersionAddendum
configuration option for sshd (but you''re talking about adding it to
ssh):

(from ChangeLog):
djm@cvs.openbsd.org 2012/04/12 02:42:32
 [servconf.c servconf.h sshd.c sshd_config sshd_config.5]
 VersionAddendum option to allow server operators to append some arbitrary
 text to the SSH-... banner; ok deraadt@ "don''t care" markus@

and then making that string interpret the standard %-escapes, so a
client who wants to use this feature could do:

 ssh -oVersionAddendum=Host:%h server.example.net

That configuration option seems flexible and generic enough that it
would fit with the rest of the ssh interface (and it would enable
distros like debian to drop diffs like
debian/patches/package-versioning.patch in favor of a one-line addition
to /etc/ssh/ssh_config).  I''m not convinced that a feature like this is
worth allocating one of the few remaining short option flags (-H) though :)

Another thought about your proposed proxy: ssh''s DH key exchange
results
in a shared secret based on the exact contents of a bunch of stuff,
including the connection strings.  Either all of your backend servers
need to offer the exact same connection string as your proxy offers, or
your proxy needs to wait to receive the client''s connection string
before forwarding the connection to the backend server.

If you choose the former, then when dealing with system upgrades,
you''ll
need to upgrade your entire server farm at once, so that the connection
strings stay synchronised.  This kind of "flag day" makes maintenance
difficult.

If you choose the latter, and there are any SSH clients out there that
wait for the server''s connection string before sending their own, then
those clients will deadlock when connecting to your proxy.

	--dkg



_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Michael Stone wrote:
>> Why have a proxy if it allows to connect to any backend machine
>> without authenticating the request anyway?
>
> Because IPv6 isn''t widely deployed yet.
The imaginary use case was virtual hosts with a www. hostname
example, so the backend machines are presumably reachable at least
on one port already.


//Peter

Hi.

On 11/13/2013 06:59 PM, Daniel Kahn Gillmor wrote:
> On 11/13/2013 08:25 AM, Hannes Hörl wrote:
>
>> This all is just my imaginary use case. Anyhow, I think you could call
>> the thing I''m thinking about "poor man''s SNI[0]
for SSH" ...
>
> I''m not sure why it would be "poor man''s" --
your proposal sounds very
> similar to SNI from TLS.
"poor man''s" because its just fiddling with the
"Protocol Version
Exchange" string and not introducing new stuff in the protocol ...
> [ ... Problems of SNI ... ]
> Note that SNI (in either TLS or in your SSH proposal) is not
> "negotiated" in a strict sense. Is it offered by the client to
the
> server in the clear, in the hopes that it will be supported by the
> server (but willing to be ignored if it is not supported).
Yes, that''s exactly how i thought about it ...
>> So my question(s) rephrased:
>> Why isn''t there anything like SNI for SSH? For security
reasons? Is
>> there no demand? Is there a better solution which I don''t know
of?
> Is it worth having clients advertise the server''s name in the
clear on
> the network if there is no proxy in use?  Your proposal neatly avoids
> this question by making it disabled by default.
What is the problem, when the client advertises it? In the case that
I''m
thinking about the DNS advertises the fact, that some hostname is in my 
net directly or NATed or whatever) anyways.
If I''d setup portforwarding on different ports on the proxy to reach
the
sshd of the different backend machines and having multiple hostnames 
(for my http proxy) point to the same proxy IP, how would this be safer?

Anyways, I wouldn''t make it a default to send the hostname, because
it''s
just ignored on any server except my proxy thingy and therefor useless 
in all other cases.
> You should also realize that some distributors patch their clients to
> add a comment string there anyway (e.g. Debian openssh puts
"Debian" in
> the comment there).
Ah ok, I didn''t realize this while playing with (obviously) just the 
unpatched version.
> So your proxy could get quite confused if it tries
> to hand the connection off to the "Debian" backend.
Mh. If the proxy doesn''t know about a backend machine
"Debian" there
would be no problem. If there is a backend machine with said name a 
connection would be established, but the user (hopefully) cannot 
authenticate.
> If this is a space for hiding other sorts of cleartext connection
"hints", then you
> probably want to distinguish your "SNI" hint from other hints. 
you
> could perhaps do this by declaring it with a specialized prefix, like
> "Host:", to distinguish it from othe uses of the comment field. 
That
> way a comment like "limburger Host:server.example.net" would be
cleanly
> parseable.
That''s something I thought about an would somehow be possible. But If I
understood the RFC, the max length is 253 (\r\n not counted). So packing 
to much stuff in the comments field isn''t even possible anyway.
> If you decide this is really something that you want, I''d
recommend
> modeling your change on the patches that added the VersionAddendum
> configuration option for sshd (but you''re talking about adding it
to ssh):
>
> (from ChangeLog):
> djm@cvs.openbsd.org 2012/04/12 02:42:32
>   [servconf.c servconf.h sshd.c sshd_config sshd_config.5]
>   VersionAddendum option to allow server operators to append some arbitrary
>   text to the SSH-... banner; ok deraadt@ "don''t care"
markus@
>
> and then making that string interpret the standard %-escapes, so a
> client who wants to use this feature could do:
>
>   ssh -oVersionAddendum=Host:%h server.example.net
>
> That configuration option seems flexible and generic enough that it
> would fit with the rest of the ssh interface (and it would enable
> distros like debian to drop diffs like
> debian/patches/package-versioning.patch in favor of a one-line addition
> to /etc/ssh/ssh_config).
Thank you for the pointer, I will look into this.

But anyway: the information would have to be transfered in the first 
(unencrypted) line. And - even more when distributors or other clients 
already use the comment field - space there is rare.
Any other implementation of my idea would need updates in the protocol 
itself, and I think i don''t want to got there ... ;)
> I''m not convinced that a feature like this is
> orth allocating one of the few remaining short option flags (-H) though :)
Haha ... I think you realized, this was just an example ... :)
> Another thought about your proposed proxy: ssh''s DH key exchange
results
> in a shared secret based on the exact contents of a bunch of stuff,
> including the connection strings.  Either all of your backend servers
> need to offer the exact same connection string as your proxy offers, or
> your proxy needs to wait to receive the client''s connection string
> before forwarding the connection to the backend server.
Yes.
> If you choose the former, then when dealing with system upgrades [...]
No, that''s not what I intended. This sure is a PITA.
> If you choose the latter, and there are any SSH clients out there that
> wait for the server''s connection string before sending their own,
then
> those clients will deadlock when connecting to your proxy.
Ok. Somehow I was convinced, the client has to send its connection 
string first; I must have gotten confused at some point. After your 
description and a short test it''s obvious this is not the case. So my 
approach (waiting for the client to send its connection string) would 
exactly have the problems you pointed out.


However, you answered most of the questions I had in mind and pointed 
out problems with my approach. Thank you very much!

Nevertheless: I definitely would like to have some kind of SNI or 
similar for SSH :)


Thanks again & bye, Hannes

Hi

On 11/13/2013 07:22 PM, Peter Stuge wrote:
> Michael Stone wrote:
>>> Why have a proxy if it allows to connect to any backend machine
>>> without authenticating the request anyway?
>>
>> Because IPv6 isn''t widely deployed yet.
>
> The imaginary use case was virtual hosts with a www. hostname
> example, so the backend machines are presumably reachable at least
> on one port already.
No. I thought of the case, where the backend machines are not reachable 
from the outside, but http goes through haproxy or something similar.
So from the outside hostnames point to the proxy, but on the internal 
network they resolve to their internal IPs.

Hannes

Hannes Hörl wrote:
>> The imaginary use case was virtual hosts with a www. hostname
>> example, so the backend machines are presumably reachable at least
>> on one port already.
>
> No. I thought of the case, where the backend machines are not reachable 
> from the outside, but http goes through haproxy or something similar.
> So from the outside hostnames point to the proxy, but on the internal 
> network they resolve to their internal IPs.
Ie. they are reachable.

Why not make the HTTP proxy understand CONNECT (if it doesn't
already) and use a suitable proxycommand in your ssh config?


//Peter
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 11/13/2013 02:10 PM, Hannes Hörl wrote:
> [dkg wrote:]
>> If you choose the latter, and there are any SSH clients out there that
>> wait for the server''s connection string before sending their
own, then
>> those clients will deadlock when connecting to your proxy.
> 
> Ok. Somehow I was convinced, the client has to send its connection
> string first; I must have gotten confused at some point. After your
> description and a short test it''s obvious this is not the case. So
my
> approach (waiting for the client to send its connection string) would
> exactly have the problems you pointed out.
i don''t think the spec insists on an ordering.  in fact, i think both
are supposed to send their strings immediately, if i''m reading it
correctly.  My point was that if there is a client that happens to wait
for the server string (i don''t know of one that does, but i
haven''t done
wide testing for this behavior) then it would deadlock on your proposed
proxy.

Regards,

	--dkg



_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev