>> 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. similar can be true for the client side: ssh -b 1.2.3.4 -w any office ssh -b 2.3.4.5 -w any office allow-hotplug /tun*=tun iface tun inet manual up route add default dev "$IFACE" will also soon have to end up with specific single-interfaces nondynamic config. imagine mixing this: the office knows several bridges and possibly even other uses of tun/tap. might be the same for clients. now tun/tap interfaces do not have to be named tun* or tap*. namespaces can be used. so: clients: ssh -o "Tunnel Ethernet" -w officebridge1:officebridge1-alice office-hub on the hub: allow-hotplug /officebridge1-*=officebridge1-port iface officebridge1-port inet manual bridge officebridge1 and client: ssh -b 1.2.3.4 -w office1:office-alice1 office ssh -b 2.3.4.5 -w office2:office-alice2 office allow-hotplug /office*=office iface office inet manual up route add default dev "$IFACE" and server: allow-hotplug /office-alice*=office-alice iface office-alice inet manual up route add 3.4.5.0/24 dev "$IFACE" what is the point of artificially restricting names to just tun\d+ and tap\d+ ? _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
