On Wed, 30 May 2018, dev@xxxxxxxxxxxxxxx wrote: > >> the fact that ssh insists on tap* and tun* tun/tap-device-names is a > >> real nag and prevents from nice and easy solutions in some cases. > > > > Could you offer some examples? > > some client: > ssh -o "Tunnel Ethernet" -w any office > > next client: > ssh -o "Tunnel Ethernet" -w any office > ...and so forth. > > interface configuration on the hub for all clients: > allow-hotplug /tap*=tap > iface tap inet manual > bridge hub > > now some other client needs a specific config on the server or there > happens to be something else wanting to use a tap-interface for > something else => every single client's interface has to be configured > specifically, all interfaces have to be statically assigned to > clients, clients have to reserve every single interface they might > want to use in advance. Couldn't you avoid this by picking high numbers for the ones that you need specific configuration for? This would leave the rest free to choose "any" since they allocate lowest numbered tun/tap devices first. > client: > ssh -b 1.2.3.4 -w office1:office-alice1 office > ssh -b 2.3.4.5 -w office2:office-alice2 office Alternately we could add a server-side map of number->interface name. E.g. by extending the existing PermitTunnel; something like: PermitTunnel 0:office1 to indicate a client requesting device '0' gets interface "office1" (we'd probably need to flesh this out a little more...) > what is the point of artificially restricting names to just tun\d+ and > tap\d+ ? I didn't write the tun/tap support, but I guess it was partly the original author not seeing the need for more flexibility and partly some caution in not wanting to allow the client the specify interface names directly. Now, we're not totally stuck with the existing message format (it is an extension after all), but adding a new message that includes names does impose a number of costs that I'd like to avoid if possible. Would either of the above alternatives solve your use-cases? -d _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
