Mailing List Archive

On Sun, 12 Jan 2020, Nico Schottelius wrote:

> I was wondering what you think about SNI (server name indication)
> support to OpenSSH?

Oh, please absolutely not. SNI is a privacy violation in HTTP, and
otherwise just a poor excuse to continue running NAT and/or IPv4.

bye,
//mirabilos
--
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database” (#nosec) ??? Please let MySQL and MariaDB finally die!
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Sun, Jan 12, 2020 at 5:07 AM Nico Schottelius
<nico.schottelius@ungleich.ch> wrote:

> Background: SSH is one of the rare protocols in the data center that
> cannot be easily load balanced, proxied or made highly available.

you can pretty easily load balance sshd with host certs.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Hey Thorsten,

Thorsten Glaser <t.glaser@tarent.de> writes:

> On Sun, 12 Jan 2020, Nico Schottelius wrote:
>
>> I was wondering what you think about SNI (server name indication)
>> support to OpenSSH?
>
> Oh, please absolutely not. SNI is a privacy violation in HTTP, and
> otherwise just a poor excuse to continue running NAT and/or IPv4.

you might have misunderstood me. The purpose of my request was to enable
transition towards IPv6 networks. Concrete, the following scenario:


[ v4 Internet ]
|
[ v4 to v6proxy ]----------------------------
| | |
[v6 only host 1] [v6 only host 2] [v6 only host 3]
| | |
[ v6 Internet ]----------------------------

If we had any possibility to support this scenario, a lot of services
that we see could be shifted to IPv6 only hosts today and not tomorrow.

The "migrate everyone at once" approach really doesn't work in real
life, you need to have either network providers or content providers do
a start. And at this point a lot of things can already be shifted to
IPv6 only machines with still being accessible from the legacy Internet.

Besides ssh.

Let me rephrase my original question, I don't actually want SNI:

Is there any way to create a multiplexing proxy for SSH?

Best regards,

Nico



--
Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Have you ever considered using ssh's proxy-command for this?
I have a similar setup, works great for me.

--

Martin

> Have you ever considered using ssh's proxy-command for this?
> I have a similar setup, works great for me.

I think the intended application is to proxy through a proxy host provided by the service provider. If SSH had a SNI like feature where a host identifier was passed in plain text during the initial connection. This way the user would just need to register their host identifier and IPv6 address (e.g. via AAAA DNS records), and the service provider wouldn’t need to maintain a list of allowed users. The proxy would have no more access to the contents of the SSH connection than any other intervening stateful firewall.

I don’t see a compelling security reason not to optionally include the hostname in the clear, any eavesdropped near the client would observe the DNS request and the SSH TCP connection.


-Dustin

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

On 2020-01-12, Dustin Lundquist <dustin@null-ptr.net> wrote:

> I think the intended application is to proxy through a proxy host provided by the service provider. If SSH had a SNI like feature where a host identifier was passed in plain text during the initial connection. This way the user would just need to register their host identifier and IPv6 address (e.g. via AAAA DNS records), and the service provider wouldn’t need to maintain a list of allowed users. The proxy would have no more access to the contents of the SSH connection than any other intervening stateful firewall.

You can do this with a jump host, see ProxyJump in ssh_config(5).

--
Christian "naddy" Weisgerber naddy@mips.inka.de
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Christian Weisgerber <naddy@mips.inka.de> writes:

> On 2020-01-12, Dustin Lundquist <dustin@null-ptr.net> wrote:
>
>> I think the intended application is to proxy through a proxy host provided by the service provider. If SSH had a SNI like feature where a host identifier was passed in plain text during the initial connection. This way the user would just need to register their host identifier and IPv6 address (e.g. via AAAA DNS records), and the service provider wouldn’t need to maintain a list of allowed users. The proxy would have no more access to the contents of the SSH connection than any other intervening stateful firewall.
>
> You can do this with a jump host, see ProxyJump in ssh_config(5).

That is correct, but requires client configuration. This only works if
you can communicate with each and every user.

The problem I am trying to solve is: there are thousands of users on
IPv4 only networks who I cannot all communicate with. And they need to
access resources on IPv6 only systems.

The typical jump host / proxy command approach surely works, but only
for a small percentage of the users. The big part actually reaches out
to the support and has severe problems if they cannot just use "plain
ssh" (i.e. need to configure ssh or don't land on the target host
immediately).

I hope the motivation and scenario is understandable and it would be
very much appreciated if there was any way to dispatch to multiple end
hosts with ssh directly. Whether that's via SNI or another mechanism, I
don't have a strong opinion on.

Best regards,

Nico

--
Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 2020/01/13 11:10, Nico Schottelius wrote:
>
> That is correct, but requires client configuration. This only works if
> you can communicate with each and every user.
>
> The problem I am trying to solve is: there are thousands of users on
> IPv4 only networks who I cannot all communicate with. And they need to
> access resources on IPv6 only systems.
>
> The typical jump host / proxy command approach surely works, but only
> for a small percentage of the users. The big part actually reaches out
> to the support and has severe problems if they cannot just use "plain
> ssh" (i.e. need to configure ssh or don't land on the target host
> immediately).

Even if such a mechanism were added, you would be waiting a long time
before new enough OpenSSH versions filter through to the usual client
OS, and for other clients to gain support. It wouldn't be an easy way
out for your problem.

> I hope the motivation and scenario is understandable and it would be
> very much appreciated if there was any way to dispatch to multiple end
> hosts with ssh directly. Whether that's via SNI or another mechanism, I
> don't have a strong opinion on.
>
> Best regards,
>
> Nico
>
> --
> Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch

If you have users that are wanting to access a v6-only system but
are themselves unable to setup their own v6 access, the easiest way is
probably web-based ssh (via a dual-stack host). If they want more it's
not so hard to setup v6 via a tunnel/VPN.

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

On 12/01/2020 15:39, Nico Schottelius wrote:
>
> Hey Thorsten,
>
> you might have misunderstood me. The purpose of my request was to enable
> transition towards IPv6 networks. Concrete, the following scenario:
>
>
> [ v4 Internet ]
> |
> [ v4 to v6proxy ]----------------------------
> | | |
> [v6 only host 1] [v6 only host 2] [v6 only host 3]
> | | |
> [ v6 Internet ]----------------------------
>
> If we had any possibility to support this scenario, a lot of services
> that we see could be shifted to IPv6 only hosts today and not tomorrow.
>
> The "migrate everyone at once" approach really doesn't work in real
> life, you need to have either network providers or content providers do
> a start. And at this point a lot of things can already be shifted to
> IPv6 only machines with still being accessible from the legacy Internet.
>
> Besides ssh.
>
> Let me rephrase my original question, I don't actually want SNI:
>
> Is there any way to create a multiplexing proxy for SSH?

FWIW a provider called Mythic Beasts[0] seem to have much the same issue
as you. They provide IPv6-only servers and need to provide ssh access to
them over IPv4. What they do is multiplex based on port number. For
example, to ssh to one server I run:

ssh -p 5167 root@ssh.monit_test.hostedpi.com

and to another I run:

ssh -p 5161 root@ssh.test.hostedpi.com

It's not quite as slick as automatically routing based on the domain
used for access but does the trick well enough for them and is used in
production.

[0]: mythic-beasts.com
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 01/13/2020 11:10 AM, Nico Schottelius wrote:
> The problem I am trying to solve is: there are thousands of users on
> IPv4 only networks who I cannot all communicate with. And they need to
> access resources on IPv6 only systems.
>
> The typical jump host / proxy command approach surely works, but only
> for a small percentage of the users. The big part actually reaches out
> to the support and has severe problems if they cannot just use "plain
> ssh" (i.e. need to configure ssh or don't land on the target host
> immediately).

Out of interest:
1. If an extended mechanism were to be implemented, which server pubkey
do you expect to be seen/stored/verified by the client? The proxy's
/ v4 middlebox's, or the v6 backend's? Or would you require that all
server-side machines use the *same* host keypairs?
2. Are there any clients *with* v6 accessing the same backends? Via
generic v6? How is the distinction made, FQDNs given in the public
DNS with the proxy's v4 and the backend's v6 IP and leave the
selection to the client? Could client machines *switch* between both
modes, short of an all-out reconfig by the sysadmins' hands?

Proxy pubkey (? backend pubkey) for v4 and clients can switch between v4
and v6 ==> Users get MitM alerts after every switch.

Backend pubkey (? proxy pubkey) for v4 ==> Any user using the
ssh-keyscan tool will probably thus stuff his known_hosts file with the
*wrong* one(s).

Etcetera.

Regards,
--
Jochen Bern
Systemingenieur

Binect GmbH
Robert-Koch-Straße 9
64331 Weiterstadt

Hey Jochen,

Jochen Bern <Jochen.Bern@binect.de> writes:

> On 01/13/2020 11:10 AM, Nico Schottelius wrote:
>> The problem I am trying to solve is: there are thousands of users on
>> IPv4 only networks who I cannot all communicate with. And they need to
>> access resources on IPv6 only systems.
>>
>> The typical jump host / proxy command approach surely works, but only
>> for a small percentage of the users. The big part actually reaches out
>> to the support and has severe problems if they cannot just use "plain
>> ssh" (i.e. need to configure ssh or don't land on the target host
>> immediately).
>
> Out of interest:
> 1. If an extended mechanism were to be implemented, which server pubkey
> do you expect to be seen/stored/verified by the client? The proxy's
> / v4 middlebox's, or the v6 backend's? Or would you require that all
> server-side machines use the *same* host keypairs?
> 2. Are there any clients *with* v6 accessing the same backends? Via
> generic v6? How is the distinction made, FQDNs given in the public
> DNS with the proxy's v4 and the backend's v6 IP and leave the
> selection to the client? Could client machines *switch* between both
> modes, short of an all-out reconfig by the sysadmins' hands?
>

I love those two questions. I'll answer it with how TLS proxying works,
because that works quite nice:

- The proxy does not have *any* certificate on our HTTPS servers
- The proxy analyses the first few bytes, listens for the name in the
TLS handshake and then sends the buffered request to the correct
backend

In terms of DNS management, how it is done for HTTPS:

- AAAA -> goes directly to the target host
- A -> goes to the proxy

The proxy itself is there also stateless. If it is configured for
example.com, it will lookup the AAAA entry and forward the packet
without needing to know anything special about the IPv6 backend.

So to answer your question: the client sees the same pubkey for both
proxied and non-proxied connections.

You can test that for yourself by curl'ing https://webmail.ungleich.ch.
The host providing that service is only reachable by IPv6 and IPv4 is
handled by the proxy.

For SSH this could work very similar, it does not need full blown X.509
certificates or a rich protocol like http to support this. A simple
"Host: target-host" alike greeting from the client would suffice.

Cheers,

Nico

p.s.: HAProxy, which we use, can even forward the original client IP to
the end host using the "proxy protocol".

pps: The whole haproxy configuration for it looks as following. It
supports smtps, imaps. https and http at the moment.

# ipv4 https frontend
frontend httpsipv4
bind ipv4@:443
mode tcp
option tcplog
tcp-request inspect-delay 5s
tcp-request content accept if { req_ssl_hello_type 1 }
default_backend httpsipv4

backend httpsipv4
mode tcp
use-server webmail.ungleich.ch if { req_ssl_sni -i webmail.ungleich.ch }
server webmail.ungleich.ch ipv6@webmail.ungleich.ch
...


--
Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Mon, Jan 13, 2020 at 05:14:02PM +0100, Nico Schottelius wrote:
> p.s.: HAProxy, which we use, can even forward the original client IP to
> the end host using the "proxy protocol".
>
> pps: The whole haproxy configuration for it looks as following. It
> supports smtps, imaps. https and http at the moment.
>
> # ipv4 https frontend
> frontend httpsipv4
> bind ipv4@:443
> mode tcp
> option tcplog
> tcp-request inspect-delay 5s
> tcp-request content accept if { req_ssl_hello_type 1 }
> default_backend httpsipv4
>
> backend httpsipv4
> mode tcp
> use-server webmail.ungleich.ch if { req_ssl_sni -i webmail.ungleich.ch }
> server webmail.ungleich.ch ipv6@webmail.ungleich.ch
> ...
>

Neat. I do something similar: in order to circumvent obnoxious airport /
coffee shop firewalls that block non-HTTPS traffic, I configured haproxy
to offer 'SSH over HTTPS'. haproxy terminates the HTTPS connection
(which is SNI-aware) while sshd on the target machine terminates the
tunneled SSH connection.

In ssh_config, I use ProxyCommand to invoke gnutls-client to create the
HTTPS connection.

You've indicated that you don't want to compel your users to make
significant changes to ssh_config, but others in this thread have noted
that an SNI option for OpenSSH will take some time to propagate from
ideation through development through widespread* deployment

Would this SSH-over-HTTPS option be worth considering for your use case
while the SNI-aware OpenSSH gets more backers? (I think I might be one,
now. You may wish to ask for Proxy-Protocol support, also.)

* sufficiently widespread that your users can get packages from distros

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

Hi,

On Mon, Jan 13, 2020 at 03:16:00PM +0000, Jochen Bern wrote:
> Out of interest:
> 1. If an extended mechanism were to be implemented, which server pubkey
> do you expect to be seen/stored/verified by the client? The proxy's
> / v4 middlebox's, or the v6 backend's? Or would you require that all
> server-side machines use the *same* host keypairs?

I'd do the "SNI" part before exchanging server host keys ("just as it is
done in https, for good reason"). That way, every backend can have its
own key. The "middle box" would see some unencrypted handshake, but
afterwards would have no more knowledge of the connection than any
IP router or proxy in the path.

Actually *doing* it sounds like you need a protocol change (more than
"just an option after the key handshake"), as the server sends it
"SSH-2.0..." message first, which would have to be deferred until the
client tells it where it wants to connect to... so, not really trivial
(and back to square one, might take longer to roll out upgraded clients
than to roll out v6 to those clients).

gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de

Ciao Luca,

Luca Filipozzi <lfilipoz@emyr.net> writes:
>> [ ... ]
> Neat. I do something similar: in order to circumvent obnoxious airport /
> coffee shop firewalls that block non-HTTPS traffic, I configured haproxy
> to offer 'SSH over HTTPS'. haproxy terminates the HTTPS connection
> (which is SNI-aware) while sshd on the target machine terminates the
> tunneled SSH connection.
>
> In ssh_config, I use ProxyCommand to invoke gnutls-client to create the
> HTTPS connection.

Quite nice as well!

> You've indicated that you don't want to compel your users to make
> significant changes to ssh_config, but others in this thread have noted
> that an SNI option for OpenSSH will take some time to propagate from
> ideation through development through widespread* deployment

I perfectly understand that. At the moment we give out a wireguard
IPv6 VPN for free to all users, which also has the nice side effect of
giving anyone anywhere (even behind cgnat) IPv6 connectivity.

Surprisingly adding a totally new program with totally different
characteristics so far turned out to be easier than having users edit
their ssh config.

> Would this SSH-over-HTTPS option be worth considering for your use case
> while the SNI-aware OpenSSH gets more backers? (I think I might be one,
> now. You may wish to ask for Proxy-Protocol support, also.)
>
> * sufficiently widespread that your users can get packages from distros

I might have mixed up two cases in my previous mails a bit, which share
a lot properties:

a) enabling IPv4 to IPv6 users
b) enabling load balancing for multi clusters

The (b) case has 1 name per cluster, each serving multiple nodes behind
the name. (b) is currently solved using round robin DNS with a 60s
timeout. And yes, indeed all those nodes have the same host keys and
it needs 1 public IPv4 address per cluster.

Both cases would significantly profit from an ability of dispatching by
name or intent, not only for us, but also other organisations we work
with.

So I am fine with taking some time to find a good solution that can be
agreed on and waiting for all the ripple effects, because I literally
see the potential of making life easier for thousands of people.

Best regards,

Nico

--
Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Good evening Gert,

Gert Doering <gert@greenie.muc.de> writes:
> On Mon, Jan 13, 2020 at 03:16:00PM +0000, Jochen Bern wrote:
>> Out of interest:
>> 1. If an extended mechanism were to be implemented, which server pubkey
>> do you expect to be seen/stored/verified by the client? The proxy's
>> / v4 middlebox's, or the v6 backend's? Or would you require that all
>> server-side machines use the *same* host keypairs?
>
> I'd do the "SNI" part before exchanging server host keys ("just as it is
> done in https, for good reason"). That way, every backend can have its
> own key. The "middle box" would see some unencrypted handshake, but
> afterwards would have no more knowledge of the connection than any
> IP router or proxy in the path.
>
> Actually *doing* it sounds like you need a protocol change (more than
> "just an option after the key handshake"), as the server sends it
> "SSH-2.0..." message first, which would have to be deferred until the
> client tells it where it wants to connect to... so, not really trivial

I tend do disagree with the non-trivial statement here, but it might
only be because I am a simple minded person. In the last message where I
sent the haproxy configure you might have noticed the 5 second
delay/buffer.

Even with the server sending first, this does not look very hard to
me. As a sketch:

client->proxy [tcp connect]
proxy->client [SSH-2.0-Proxy_1]
client->proxy [SNI]
proxy->endhost [tcp connect]
endhost->proxy [SSH-2.0-OpenSSH_8.1]
proxy->endhost [SNI]

From this state on the proxy can forward all traffic from both sides.

> (and back to square one, might take longer to roll out upgraded clients
> than to roll out v6 to those clients).

That's quite an interesting challenge. I'd love you being right here.

Cheers,

Nico

--
Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Hi,

On Mon, Jan 13, 2020 at 10:27:26PM +0100, Nico Schottelius wrote:
> b) enabling load balancing for multi clusters

This sounds like "if there is only 1 name anyway, why do you want
SNI"? This should be just standard tcp stream balancing (without
application awareness) - no?

gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Mon, Jan 13, 2020 at 1:48 PM Nico Schottelius
<nico.schottelius@ungleich.ch> wrote:

> b) enabling load balancing for multi clusters
>
> The (b) case has 1 name per cluster, each serving multiple nodes behind
> the name. (b) is currently solved using round robin DNS with a 60s
> timeout. And yes, indeed all those nodes have the same host keys and
> it needs 1 public IPv4 address per cluster.

you don't need to share private keys. you just need all your bastion
hosts to share a ValidPrincipal

host 1:
Public Key: ssh-rsa-cert-v01@openssh.com
SHA256:jfqNDw4KlRbJIvcdjgvKLKyQHvRL4/vzHv9hfO5u93g
Signing CA: ssh-rsa SHA256:qgFitzijB4IdXeJMKrLNPIdjrA6NqxL5Dk4cjyS+0GM
Serial: 8132918520001589427
Valid After: 27 Dec 19 22:01 -0800 (-400h23m35s)
Valid Before: 26 Mar 20 23:06 -0700 (1759h41m24s)
Principals:
bastion.example.com
bastion01.example.com

host 2:
Public Key: ssh-rsa-cert-v01@openssh.com
SHA256:thg+wy8J+cx2MhREYUuMv9Qxlt2TlnTei2Yq66G++kc
Signing CA: ssh-rsa SHA256:qgFitzijB4IdXeJMKrLNPIdjrA6NqxL5Dk4cjyS+0GM
Serial: 6576436632342469726
Valid After: 27 Dec 19 22:17 -0800 (-400h7m8s)
Valid Before: 26 Mar 20 23:22 -0700 (1759h57m51s)
Principals:
bastion.example.com
bastion02.example.com

clients with

@cert-authority *.example.com ssh-rsa <rsa key>

in their ~/.ssh/known_hosts or /etc/ssh/known_hosts will accept either
certificate for the name "bastion.example.com"
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Hi,

On Mon, Jan 13, 2020 at 10:52:15PM +0100, Nico Schottelius wrote:
> Even with the server sending first, this does not look very hard to
> me. As a sketch:
>
> client->proxy [tcp connect]
> proxy->client [SSH-2.0-Proxy_1]
> client->proxy [SNI]
> proxy->endhost [tcp connect]
> endhost->proxy [SSH-2.0-OpenSSH_8.1]
> proxy->endhost [SNI]
>
> From this state on the proxy can forward all traffic from both sides.

Sure. But if you do it that way, the client loses information on which
server implementation it is talking to - and given the number of bugs
and caveats that are worked around in the client based on the
"SSH-2.0-$product" message, I see this as non-optimal way forward.


> > (and back to square one, might take longer to roll out upgraded clients
> > than to roll out v6 to those clients).
>
> That's quite an interesting challenge. I'd love you being right here.

IPv6 is, at least here in DE, nicely happening in many access networks
(cable, DSL, mobile - vodafone.DE started supporting it recently!).

Where IPv6 is quite lacking is "content", so I applaud your efforts :-)

gert

--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Peter Moody <mindrot@hda3.com> writes:

> On Mon, Jan 13, 2020 at 1:48 PM Nico Schottelius
> <nico.schottelius@ungleich.ch> wrote:
>
>> b) enabling load balancing for multi clusters
>>
>> The (b) case has 1 name per cluster, each serving multiple nodes behind
>> the name. (b) is currently solved using round robin DNS with a 60s
>> timeout. And yes, indeed all those nodes have the same host keys and
>> it needs 1 public IPv4 address per cluster.
>
> you don't need to share private keys. you just need all your bastion
> hosts to share a ValidPrincipal

Nice, thanks a lot for the details!

--
Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 01/13/2020 07:55 PM, Gert Doering wrote:
> I'd do the "SNI" part before exchanging server host keys ("just as it is
> done in https, for good reason"). That way, every backend can have its
> own key. The "middle box" would see some unencrypted handshake, but
> afterwards would have no more knowledge of the connection than any
> IP router or proxy in the path.
>
> Actually *doing* it sounds like you need a protocol change (more than
> "just an option after the key handshake")

Actually doing it that way - and I admit that I can't think of a better
one off the top of my head - does *not* strike me as a change *to the
SSH protocol*. The SSH protocol would still happen, unchanged, through a
transparent connection between client and (v6/backend) server; "on the
wire", you'ld merely add a prologue (and possibly an epilogue) to the
data exchanged so as to initiate (and tear down) said transparent
connection.

However, that's essentially what SSH proxying solutions (SOCKS, HTTP
CONNECT) do, too, and all the reasons to have proxying separated from
the actual OpenSSH code and handed to separate ProxyCommand helper
applications should, I'ld guess, apply here as well.

In particular, for the v4/v6 switching as described, I'ld say that one
would want to implement a helper that works along the following pseudocode:
-- Get called by ssh (including being given "a target host" that
may be a host name or an IP)
-- Second-guess whether a plain ssh would/could connect to it with v4
or v6
(yes, I've seen machines with default-enabled v6 support sitting in
v4-only networks that would fail to connect to any v6-enabled hosts
including dual stack, because they would see and prioritize the AAAA
RRs in the DNS ... v6 support was simply *that much* out of scope
for the people maintaining those network domains)
-- If v6, establish an equivalent connection (maybe by exec'ing
netcat/nc as the helper's helper ;-) and hand it to ssh
-- If v4, open the connection (which will actually connect to the v4
frontend), send the "SNI" (in whatever format whatever software
running on the frontend requires it to be, my guess would be that
HAproxy would already be well equipped to handle HTTP CONNECT
requests ...), wait for the frontend to put you through to the
requested backend, then hand the connection to ssh

Thinking back to other proxying helpers like netcat/nc or corkscrew,
I'ld say that the new helper (3rd party software) might well have a
better "time to market" than an equivalent feature implemented in
OpenSSH itself ...

Regards,
--
Jochen Bern
Systemingenieur

T +49 6151 9067-231
F +49 6151 9067-290
E jochen.bern@binect.de
W www.binect.de

Binect GmbH
Robert-Koch-Straße 9
64331 Weiterstadt

Geschäftspost. Einfach. Besser.
Wir sind zertifiziert: https://www.binect.de/zertifikate.html
Melden Sie sich zum Newsletter: https://www.binect.de/newsletter.html

Die Portoerhöhung ist da!
https://www.binect.de/portoerhoehung-2019?utm_source=email&utm_medium=button&utm_campaign=portoerhoehung
https://de-de.facebook.com/binect/ -
https://www.linkedin.com/company/binect-gmbh -
https://www.xing.com/xbp/pages/binect-gmbh
Binect Erklärvideo ansehen: https://www.youtube.com/watch?v=LhL1BZ8fci0

Geschäftsführung: Dr. Frank Wermeyer
Unternehmenssitz: Weiterstadt
Register: Amtsgericht Darmstadt, HRB 94685
Umsatzsteuer-ID: DE 221 302 264

MAX 21-Unternehmensgruppe
?
Diese E-Mail kann vertrauliche Informationen enthalten. Wenn Sie nicht
der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese
E-Mail. Das unerlaubte Kopieren, sowie die unbefugte Weitergabe dieser
Mail oder von Teilen dieser Mail ist nicht gestattet. Jede von der
Binect GmbH versendete Mail ist sorgfältig erstellt worden, dennoch
schließen wir die rechtliche Verbindlichkeit aus; sie kann nicht zu
einer irgendwie gearteten Verpflichtung zu Lasten der Binect GmbH
ausgelegt werden. Wir haben alle verkehrsüblichen Maßnahmen unternommen,
um das Risiko der Verbreitung virenbefallener Software oder E-Mails zu
minimieren, dennoch raten wir Ihnen, Ihre eigenen Virenkontrollen auf
alle Anhänge an dieser Nachricht durchzuführen.
Wir schließen, außer für den Fall von Vorsatz oder grober
Fahrlässigkeit, die Haftung für jeglichen Verlust oder Schäden durch
virenbefallene Software oder E-Mail aus.

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of contents of this
e-mail is strictly prohibited. All Binect GmbH emails are created
thoroughly, nevertheless we do not accept any legal obligation for the
information and wording contained herein. Binect GmbH has taken
precautionary measures to reduce the risk of possible distribution of
virus infected software or emails. However, we advise you to check
attachments to this email for viruses. Except for cases of intent or
gross negligence, we cannot accept any legal obligation for loss or
damage by virus infected software.

On Sun, 12 Jan 2020, Nico Schottelius wrote:

>
> Good morning,
>
> I was wondering what you think about SNI (server name indication)
> support to OpenSSH?

I think SNI would be problematic because (until very recently) it
requires that clients advertise which host they'd like to connect to in
the clear.

However, ESNI[1] (encrypted SNI) is nearing standardisation and it might
be possible to adapt that protocol for SSH. I'd rather follow something
that has had lots of cryptographic review than cook up something for SSH
alone.

-d

[1] https://tools.ietf.org/html/draft-ietf-tls-esni-05
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev