Ciao Luca, Luca Filipozzi <lfilipoz at 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* deploymentI 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 distrosI 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
Hi, On Mon, Jan 13, 2020 at 10:27:26PM +0100, Nico Schottelius wrote:> b) enabling load balancing for multi clustersThis 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 at greenie.muc.de
On Mon, Jan 13, 2020 at 1:48 PM Nico Schottelius <nico.schottelius at 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 at 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 at 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"
Peter Moody <mindrot at hda3.com> writes:> On Mon, Jan 13, 2020 at 1:48 PM Nico Schottelius > <nico.schottelius at 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 ValidPrincipalNice, thanks a lot for the details! -- Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch