Hey Jochen, Jochen Bern <Jochen.Bern@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx ... -- Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
