openssh unix dev - May 2018 - tunnel interface names

>> 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+ ?

On Wed, 30 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?
> 
> 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

On 31.05.2018 03:03, Damien Miller wrote:
> On Wed, 30 May 2018, dev at cyphermonks.org wrote:
>> 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.
i cannot match e.g. regexps, like tun(13|14|15|16|17), just wildcards, like
tun*.
so as soon as there is more than one config for all (tun or tap), every
interface has to be entered individually.
> 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...)
this sounds like all clients requesting 0 get office1 - i guess to be helpful
this would have to be defined per client.
from my perspective and usecases this (per client mapping) would enable me to
use the interface config as intended on the server side (client side the problem
would not change), the extra indirection being just a complication (compared to
just using full device names for devices), a configuration step to stumble over.

a bit out of the line, but i just realized that an option for the server to
en-/disable each tunnel channel type would probably be generally desirable. i
added a PermitTunTap simply working like PermitTunnel for the new channel type
(and PermitTunnel is not regarded for the new channel type). so now the new
channel type will not be accidentally enabled on PermitTunnel != no setups on
upgrade.
(also, some leaks were fixed, btw - i think/hope there should be none left)
> Now, we're not totally stuck with the existing message format (it is
i guess for compatibility tun at openssh.com can't really be changed or
replaced, and the message format is static per type if i got that right...
using a new channel type just seems like the canonical approach for this case.
> 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.
what costs do you mean?
(actually i was quite surprised that the feasibility check quickly turned into a
working patch, and i was kind of delighted with what i found to be a very
straightforward and relatively small-footprint solution just following the
overall design)
> Would either of the above alternatives solve your use-cases?
mapping both client- and serverside (and per client) would make the intended
interface config (boils down to "matching some different namespaces with
wildcards") possible.
in my view the mapping would be a rather ugly part (mostly a config-obstacle).

at least in case of pubkeyauth, per-client tunnel mapping looks similar to me to
an authorized_keys config with tunnel=office1 (i.e. changing (just) this option
to full device name).
so as an example, this option uses the forced_tun_device variable, this would
have to become a string then. forced_tun_device would then have to be handled
differently and conversion to/from other device ids would be necessary - or
alternatively all devices would internally have to be handled as strings. the
new-channel-type patch changes forced_tun_device as well as the other device
identifiers to string, and just maps between id-only syntax and full-name on in-
or output.
and apart from that, the patch just adds the new channel type and the config
option and that's it.

for mapping, a good place for per-client mapping definitions has to be found or
added, device-handling will have to be dealt with in any way, and not simply
using full device names internally seems to add more code and complexity, and
mapping itself will probably also add more code and complexity than a new
channel type.

so after all i'd currently say the transparent full interface name solution,
and also the new channel type, seems to be preferable.