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. the channel type used for tun/tap forwarding is tun at openssh.com, and it defines the remote tunnel id to be integer. so from what i understood these packet definitions are static per channel type, so for compatiblity the tun at openssh.com type has to stay, untouched, and a new channel type seems to be necessary. the client will need some option to select between the two tunnel channel types, for example a ssh_config option TunnelChannelType with options tun|tuntap. switching tunnel device handling from id to name seems not to be a problem - only issue is that syntax for device config has to change from e.g. 0:0 to tun0:tun0. so the following patch is what came out when checking this for feasibility - it just works. of course i'd say this feature should go upstream - but i guess in any case the patch (against 7.6p1) needs some experienced openssh developer to look it over (and probably mend some ugly stuff). turns out the patch actually is a bit lengthy, so to avoid anyone feeling spammed, it can be found here: https://cyphermonks.org/openssh-7.6p1-devicenames.patch
On Tue, 29 May 2018, dev at cyphermonks.org 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?
>> 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+ ?