Re: port forwarding trouble

Sergio Gelato wrote:
> * Darren Tucker [2005-08-05 00:41:37 +1000]:
>
>>Sergio Gelato wrote:
>>
>>>* Frederik Eaton [2005-08-02 17:39:59 +0100]:
>>>
>>>>Also, I don't think that the "host@port" syntax suggested in the bug
>>>>comments is a good idea.
>>>
>>>At the very least it should be port@host. There is precedent for that,
>>>e.g. in FlexLM LM_LICENSE_FILE environment variables.
>>
>>Why is that better the host@port? I would bet there's precedent for
>>that somewhere too.
>
>
> Because "@" traditionally stands for the preposition "at", and most
> people find it more natural to use the host name as a scope identifier
> than the port number (maybe also because e-mail addresses have
> the host name on the right side of the @ sign).

As a mnemonic is still works ("host foo.far.com at port 22").

> And while we are comparing with e-mail addresses: how about host!port ?

I don't mind it (as long as it's not a valid char in a host name.. what
are the rules these days?), but see below.

[...]
>>>I'm not sure about URLs, but various tools simply require square
>>>brackets around the IPv6 address, as in
>>> [0:1:2:3:4:5:6:7]:port
>>
>>That would be OK for new entries but it's not backward compatible with
>>existing known_hosts files.
>
> That means the code to parse existing known_hosts files needs to be a
> little more complex. New entries should obviously use the less ambiguous
> notation.

I had to come up with a heuristic for this for another reason (sshd's
ListenAddress is slightly broken for bare IPv6 addresses) which might be
enough:

if the string doesn't contain "[]" and contains 2 or more ":"
it's a bare IPv6 address
else
do existing tests in misc.c:hpdelim()

>>Once you add an optional ":port" I don't see how it's possible to
>>reliably distinguish between IPv6 addresses created by old versions and
>>host:port indentifiers created by new versions.
>
> Don't add an optional ":port" for IPv6 address literals, then; make the
> [v6addr]:port notation mandatory in such cases.

That's reasonable since the notation with the port spec isn't backward
compatible anyway.

> If you've already allowed v6addr:port, then the ambiguity is with us no
> matter what.

I don't think that notation is permitted anyplace. It's not documented,
anyway.

> For interpreting existing known_hosts files, one could
> agree that (a) the now-deprecated notation causes a warning to be
> emitted, and (b) an ambiguous string is interpreted as matching
> either interpretation, e.g. ::1:22 is equivalent to [::1]:22,[::1:22] .

[...]
>>They're host keys, I don't see how the identifiers could be confused
>>with a user. There's no reference to users at all in known_hosts.
>
> The software wouldn't be confused, but humans who edit the known_hosts
> file might.

Since it's always numeric I can't see that being a big problem.

I'd like to use the same format everywhere if possible, but not if it
means breaking a gazillion existing known_hosts files.

--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
http://www.mindrot.org/mailman/listi...enssh-unix-dev